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[fS#Jgl 1 T — 9 ■ vi"r/V7X9 

mix* mif-9 ■ *-*tfT-? • K-xmma> 

r-9 • <*-*8Bit»** WE*y b7-9ftWV 

>y i"r ■ ^7k LXmfcfhX7-/?t . 

Ide!^^^^ MIBr-?*^!!? 
Btrt B^St-* £ »«ii4 *S - fc £*-f A* ia- 

stria h 9 ^if ^ v- 3 y • fcuwsae-f-* 

mSrf-9 • "C-x««»tJ:->-C. fffBT-^fc^tt 
Ail^tV^fFiah^y-f^^a y • *-9frt><0* v 

t J: oT^frSftS Z £ *Wftk"t**tt. 
[fl^S2] lf*«llBfiO*a-C'*oT, Sfc. 
MfB^SgT-? 5: o-;P ■ J< -y ?-f<£ £ SrJ^jrf 

i-f^coA^SttlXSXT-yTi:. 
fffBh^^lf^^ay ■ KflBSSgr-^Srn 

buIBt-* • J: -»T. «En-^W^ 

(2 Lfc**-> X , fTlB^Hr- * SrfijfB* -y M7 - * KB 
&<r££BiSiJ?-&XT-yTi:, fc^trifcfcttafc-f* 
*£. 

[H*ja3 1 7-9 ■ K-xiJwy vis*/+rzrx? 

3 fc"f strife?* o-c. 

7k. 

MiT-9 ■ HE** b"7-?£i3tt 

■S^X??^' • )\7k IXmfet&ZT vTk . 

mBr-9 • ^-z.&mmz£~>x. matmuzA* 



flfrlBXr «y 7*(ir- 99misXf- J»tz£ *>X mfZ ti& 

zkzmLktim. 

ogatAr*) i oicssajf »rm , friBT- 
9 ■ ^-xmmmT-9mmt. mmw^v. 

izhi z k **-rz k zftrnk-rtirm. 
[ii*35] mmumwrmx'ti^x. set. 

^r-yTi:. 

MiT-9 • hJIBt — ^ • ^~ 

^^5^r-^«litCL^*<oT. liriBx-^ • 

v?k. 

otibt-* • K-x®mizx*>x. mwobzm 
mk-rzirm. 

imme] rnmumniTmx'&^x. set. 
mmf-9 ■ <-mmiz£ix4K>b*%mt& 

Z7--y7k. 

mtf-9 • K-xmmizx-ox. HiriBr-^ • 
mwM^~9mmzLtzt^x. m^^tK mi 

i,zmmMtmimz®mztix\,^zk swjgt s 

^T-y7*i:, 

KriBr-^ -^-^UMJaHcJioT. HifiB^ObSr-e 
^zm^mk-thXT-vzrk. ZStsZkZmik-t 

imw%i\mmnm<7)iim\ ) z&^x. mm&x 

f-y7°(i, 

Wir-9 • <-^^^rt^T-^tgjt*\ iftfBr- 
<y b cr>9 4 7* A b tWf 
5 C i: $r^-t i: # . hJIBt-^ • ^-T^mmzi. o 
T, fffB£l?MN7'^loHH5iB^OhSrBai-rSX7 i 

x«y7-(i. 

fflBr-^ • <-X®m,?>T- 9Wm\>Wtt%? 4)V 
9tK BiTlBT-^ • <~-Ztf4«*yb<7)#X'mLlt:m 

tt-rzA^yb^m&zkZK-tkz. mibt- 

* • <-X«^gfJt «t or . *0j8&^f) 1 ofciMIB 
[0001 ] 

"Middleware For Enterprise Information Distributio 
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[0002] mnmz 

■CSi^rA- ^<yhco— Wioi,->t. -toKStf 

[00033 fl»R&*S>*f-AfcKIU 5S 

fcSBje-ftof, TktfS' • • ^-X (legacy data b 

ase) fcflHB^^^AKaMW-4*ffi4J JtfUBKRI 

[00 04] 

is 3 y j tr/Ktransactional model) SrfiSfflf •& <ltf> 
[0 0 0 5 3 mkWh 7 >"f ?^sy • ^r/PTIi, 2 

o<D7r u ir-S" a Lfc r h 5 yif ? ^ 3 y j 

Mi.. $8X7 9? 4^4 (business activity) £h 
A<^r WSM^Tfiff fclWW- * h 5 yf ? 5" 

a y*saw*£ fc#£v*. set:, h^y 

[00063 1HR%$ft.(> 
fc^**)»B#fc*41fctf- hfr»*Mlfclv/7 h*7 
x7*ttJfll/Cn*. .I<0«):3&77h*7x7?x:i:£ 
77h*>x7j MIX. £<tf)ffiii 

7 h>>x7^W#y • 77h*7X7£fl£EU »rfc 

^■f-At«E*aDi.4Cfct:li. mfiT*>4. set:. £ 
ttrttti. «nEtlDi*it3& t 'C§4Sfc:^^- i^x 

5^t<i^^ti,s„ 4stt»±. 



• V7 h*X7£«E-r6i£«**f!l*3rLT^ 
[00073 

[*»*WfcL J: 0 41883 <i^i 3irO**tf> 
li. mmaXX/U^f^ ■ t-9 • ■ V7b')x7 

-a • 77 h*7xrafW«±l|]E*Jni.*<Taftr*tt 
T*4. 
[00081 

[iSB£»ft-*-4*:#>0#&] *#Wi. ft*8ffie>ISl 
a*t*U ys/+a*^l±1f7***7^>'fc)lvffi£: LTi 
[00093 *W5ltt, r 5 1W7X7 j (middleware) 

-s/3 y • 7*0/5 A^pi^/i^ro^Afccoigi 

tC<ttBt4V7h'7X7«0ii: , C**. 5 H^»7X7tt 
r*yh»7-?«Mu (network centric) ft£ 
COi— T • >f > ? - 7 x -X^p^<7)T- ^ ^-^ COS 

ryN'T* 1 ; y^-vj (publisherjxyx^ T-f 
fc. fll«tS«Uttffl"t4«»(7> r-9-7*J*^5>f^j (s 
ubscriber)xyf tt k**tf. ^<7*U >y 

2^t*-yh!7-^-C«aSilTV^. 
^■yh7-^(i. rffi^tjJ:i^6jgj (store and forwa 
rd) * -y h*7-^TA 0 . ^co^-r 4 y/(routiag)(i 
r rt^S-S*i:-ri)j (content-based) t^Tft -5. 

rt^^U y ^A-'^T'X^ 7-f ^7 h'P^(z2-^< 
*>*Cli*^. J2lTt=K»T*Hlt0ITtt» 1f$8{i^<0 
•9-7*x ^ 7 -f v <(dfeff LT^ffiS *l* . 
[00 103 WTt:ie«tl)IISfi0iJT1i. if $g<02#W 
#fi[(basic quanta) r^/^^hj (event) fcifctc. y« 
7**Jy^tt-f^hfc4»t. IfT'^^^-f^i. 1** 

^ ^ >f xijbwta l^s* k -at s ^<yh^ 

[00 113 ^*fc J H«rt«™Wfc:«ffS*ift. a-7* 

u y x-r t 7 4 mm wwmmtomn i 

^yh?rSfiL. ^TO«»ar^7*x^5>f >Vz*<?>4 

^XT^ix^m^tt^^x^Kyh^mth 
[00123 vmziffi?h$mmii. /*rv -r^a 

XW7'X774^m<?>77Vl--is3y- 7*n^75 
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V? • 4 yf— 7i- X (API :Application Program 
minslnterface) AP I \t s 'yx-vfci 

f47W?V-vi'-riSlVy-7Z? : 74>V&. AP I 
£U:#oT£S&$*i*:>f ^?-7x-x#JII*tefflL 

facilities)^ 53:, 7 • ^ 

H3t*41frK-hfc*tf. JaTfciMM- 

[0013] &Tizwmt&*mnmmmte. ^ni/ 

• y\- H »7X7£ -/XfACgil:^ L , i-if*^ 

i&MzWt£o bt&l>e>X'$>t. S/XrArtoSfi 
li#H8W> r-f^yhj ££^vvc*t*>*i4<0T\ #8 

U ZUZWeTrVtr-is s PCfci 

wfc&fTOc**. jaTtEat*»»«tt. aft** 

i'x? hS^Wistributed-object environment) 5: jf'Jffl 

— #(C0RBA: Common Object Request Broker) &Mt&t 
4. 

[0014] ***fc>IWfc i ft fc . *QJHNC*}lvc 
JWWt3*U£<Ett3*i4J:3fc, r-* • 

^-^.2:A-7*U -y ^-v/"^*?^ A • * y 
fcfflRU T — 9 ■ <-Xtf*v YV-tlZlKy h£ 

*ra$/XrAteJ^TIifT3*l4a:aXF-y7>6j* 
4. EP^>. 'Jy?£fflSU h7yif7^ 3 >i^3y 
■ 7o/7A(:J:-9T, t-? • *-x#t- 

«kdt;-f-&Xr-yTi:, *-y h7-^t:t5^tf-^ • 

•yrfc. r-^ • ^-XfcioT. Wkr-? • 

*-^Wittt4-X7 l yrfc. mEr-fiZttAtih 
Z b £*rf a- VfrhnXj) 4 *r -y 7" fc , 35 

-?toI*n*4XT yTfc. r-* • 

• t-^A^^-y-k-^L^-DT. 

[0015] a w*i J: wmsxt 



Tfc 0 . *>4 VM*«ra^Kt^a fct?Wi I b ifi 
*^T1*^t=IWiUT*4W6lsJ:t«ll*^i>*. * 
[0016] SStfliBtt. *wwifc:***i«toH»* 

*4. 

[00 17] 

Tffiffl LT . tettR«aS»t=ma-t4 £ i: b 

-tl. 

[0018] 1. 81® 

H 1 li. *J^SrV%itHe J: 4 * •/ h v 
ti-^ • •/XfAlOO^/n^itftS. *7h 
7-?l3Vti-^ • j/XfA 1 0 0{±, S3a<0A - 7* 

U y^+102, iio, 1 1 etiXvmLW?*? 

7^*104, 112, 1 18fc*tr. ^7"'J7^1 
0 2fc-^7*X^7>fA*i 04(i. A7*l 065rat"C* 
•y hV-^ 1 2 0fc««3iVO*4. vt7*U y£^^ 1 1 

o&£W7*?y4^i 1 21^7*1 0 8 tatr* 

■y 1 2 0Kaf«$itTV^4. ^*7*U -yi^ 1 1 

6k-rrx^5-f^l 18li. A^l 14*iltr*«y 
1 2 0t:aaiS<fC^4. ^7*1 0 6fc«J:t/-5- 
<lKS«$<lTV^4vC7*Uy^tJj:^7*^^9-f^ 
^ 1 T'J h'J (territory) 1 30fcft4. A/1 0 
8, 1 14tiXVZtll>izmifcZilX^Z>^7 ,l J>yi'Ar 
&3iW7Z?y4JVtm2T > )h l )14 0iZt>&. * 
OflfccOr'J bV (H^-tfi*) i*vh7-^120t:tt 

»t4ikti-4. 

[ 0 0 1 9 ] m 1 fcfcl vCjSOKTSf*- «k 0 #^7*'J 

A-4M1 02. 104, 106) . H-ayta-i' 
(108, 110. 1 12) . 4fc«g«|^>3yta- 
^fcilfR— 3^K*-^ <1 14. 116. 118) 
«^"Wl3&»^i*^i3-W)it>t:EaK-4 £ i: 4 . 
A7*li 0*mJ^Lh<OA'7'll'y^'VfeJ:tfO*B>ri3LI:<0 
^7*X^9>f-"C«r#t4Cfc3&»T*4. 4fc. />7l4B 
***5tt*>A7*fc»K*4 i fcTOT*4 . 
[0020] #3>ta-^ (HltcfeV^T^If^U? 
-f) JS. CPUfc. >«Uk. Aaj^UfcSr^tfClJ: 
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wxijax* tuvwt. tvmizmm 

v\ MM. W^t, -*r*?54/N\ t»J:tf/\r 

xTfcWf-f* i fc t> TOT* * . 
[002 13 *&Bj^*ftt£JSP!l»i. V 5 'J A (Solar i 
s)^1/-t^t'- S^ri^ A— s; a y2. 4 cDT 

t-y-y • 7>f^nyxfAX • A yn-^lz-fv H(S 

un Microsystems. Inc.)?)£$ijStgT'$> 9, 

(Uni xJ^Wf^y/- ^rA^S*i;-ri,i 

sgnffimx-S) o . x/open, Ltd. tatra 

^•yXfAlOOli TCP/ 1 POia**-y h*7 
-7®firnh3/i/£teffl-f*fr\ 

li, &fe04*«fcrnh3*fcttffl"f 4 

[00223 d; Iz&m-im&MX'li. W y „ j, 
*j h7-?l 2 0±"C'&Sao-f^yN^^ 

d. /try v^*&XVV7x?94W$Wmitl£M 

ftj *?/UMBIW-4£fcfcJ:9, *«y h 7-^*^(2 
7ry^-x 3 yS:. tiJ:V5V>^ltf*ii:#T'S 

■ ?4ri,z=f>m cap*, «t> -r 4. wa^*3¥*&« 

v \ IHftallflfiWtfcTftH tide i £ fciMW-* 

[0023] zz izMffitmmommit „ r ^ 
fcj*mi tttffl-r*. ?rx??-f/<tt. -i^y h 

. -r z KEttt « uttrai , >f ^y b (c« 

i/c r^fcit^Mj nmmm+i. zmm 

A#>f <y h fcA, 7 r £A*iT*i < i i: 4 . 

HttC. /try ■V'fAfJ'iJlifiit? ■ v4 

[ o o 2 4 3 z z wsBctimmt, '^max"m 

/vri 0 6coia^7*ii. /try -y^tJi 

t^/*fct4ir7*^^5>f^'Co«fflarMitft*. /try 



VYl fclfci;. /try ys^tt r /£&J (advertisemen 
47. b'n£?lz*til>Z&mU:o kix^&fr M 

itr. «b, #-f^h • byxr*%4-f**. *> t= 

y* h-/KQfSie £*ytr y -y ^■v*^5ii'Cv%s 
LX. OfcWW yS/+Cov^TOflW)flMRt*tf. 

[002 53 II. ^Ov^&jLt/y-yxfyJ't 
HT««TI1. TT y ^-i/ a y ( y -y y+Jfcli 

a vxy-)^ht&{z-sm%^v?\z^\\xwtt 

A <y h (ciW* RfcSIMH-* -y 7* 

5-?m*®mmX'77V?- : s3y (J*7V visits 
XWfXtJJrt) JBy7h>7XTi»*. API (2 

<y A T\zn ixmLlM <y h^/w-^y 

[0 026 3 02(4. Witf, JV/Vvis-YtoittT 

rv y-is 3 y £^7±iz4 yxY-iv-fh mzmf-f 

4XT"yr*jKt7a--f-*-h'Cft4. 03J4. 4 

yxh-^L^^y -y^^s-f^yhS-^a-r-5 
a- • f-v-hTfcl.. *fclttfej:3e A-yy «yi^ 

zttmtLw 

[00273 zzizitmimmu. jiyhvm 
(4»> feitxgm <to) fc+'&fc-ri. /try -y^ 

Ky h 4 i: 3 tcT* Kli. /try «y 5^ 

&iftM:l1tit&tti>%:\\ J^yhiMm&b&ho 
fc-f /try •y^ J r*iJ:^-9-rx^5-f/t{45 

H2^7 s "yr2 0 2{£fcV^T. /tT 
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igO-f y^-7x-XJOTMI ( I DL:Interface Def [ 0 0 2 8 3 TT'J fr-S" 3 Sal esOrder" 

inition Language) tm^X . 4^ r-0>£iS#fiirirC' ^^r-fc^-fS wrT'J^ay 
&&. I DLIi, ^~fi?x.'9 VfsMPJV—T* (OMG:0 £j/XT^WIill 1 Tffifc:'f *L/Cfl&fcSalesOrd 
bject Management Group ) i o Jt StlfctWW-f er>f V- £ft d 77* U Jr-a/ s >t6«*A5(WE L&V * i: 
yf-7x-XZ'b&1)K J'Ohomm^m'&t: ISMtZb. rn/57liOMGI DF£J8ivC, a 
^tilffl^rig^^-m^^^ * -I £ WE*f T<0«fc 0 "SalesOrder" fc$g*r* . 

43BfcWfc«*£i>«^ TOC** .^772 0 [0029] 

//filename: order :ddl 
interface SalesOrder < 

struct Address { 

string street; 
string city; 
string state; 
unsigned long zip; 

>; 

attribute string customer.name; 
attribute Address customer_address; 
I; 

[0030] ±X&f)isyfv9ZI±* lo<MOh£ A)Vk$r4 Kyblz-o^X %4L^7^ • 

r>fy^-7x-Xj fcL,TJ6«U sa^yhrto 7r4Mt. 3-K ■ 7t4 /l^teJ»U:£SE3*i 
• rjgftj ^ LT^H-fS. JtW&ttyped function)t*N-S-f *y b?)Mm£$kb 

[0031] 1 OkLbM^y h ££H L£f£. .Ift^ ?\ *Kfccm»«&fl**tf . 7*Sales0rder?)± 

•TS. #*L<*i. OMG IDLayA JaToil 5. 

-OCfcoTlSlTU A.. y ^ - yyjJVto-Y • 7r [00 32] 

typedef struct SalesOrder .Address { 
nxsString street; 
nxsString city; 
nxsString state; 
nxsULong zip; 
} SalesOrder_Address; 

typedef struct SalesOrder { 

nxsStrig customer_name; 

Sal esOrder_address customer_address; 

} SalesOrder; 

[0033] Z<7)m<?> I DLffb'OJ: 0 tzLXU&frt rder^Ky McfchtS^l^li. 

cro^7 s y?wmmm<7)%miz$m-t&i)Hzr>^x [00363 ±E*>«R^Ji»i#je«3ftfc-f ^ h 

[00 34] ^<yh«H*^^Uc3-H • «Bt(c*Jlt4fflitt:J:-9TJK:4t.^>k=a:6ii:li. 3 

/Hi, g»Silfc^>f7 , {iiT«.'Sales0rder-f^>' Ut&liSJBL J: 0 . 4fc. ££fcEB 
r- ) <M*^£WW&fctt*>*J«:*tJ. f iWtW^o^ 5 ^*** • x^-^ffiik-f &fctf>fc 

[ 0 0 3 5] ;t7*'J 'yytKiSill^ S(>0)i:&6. 

^-fTSalesOrderCO-f^yhff^. :M 7*Sales0rderCD [ 0 0 3 7 ] >N7*tC7"n-feX • 77*U ^ a ^Sr-f f 

'f^Hii. ;M7*Sales0rder<7M*<.;^fEil. * b- /WST'n-fe.Xte, *r .y7*2 0 6K^-r«t 6 

^yx^y-fJMzximm^tz^ iojsLhwjc^tA7*fca*«i«r«ii:t^tj. ,rii 

?47*Sales0rder<^^yhp¥g<7)EP6iJ. ;M7*Sales0 b<nft&\$. J\7im->X^h4 O YV>94 7*%M 
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-rs. io*>j£#ii, ii&££tf>£&. 

^^ft'C^b (fiaRtf. SalesQrdercTH^M <r> 
lEiS. fc'Oi d fc^ry «y isvtftcM ^y b Sr^-t 
ft/Mfflitf, *5B. • MJtftfl&feUri: £ 

30 . J^yb • -f^hcOgBfcSK 

■Wc) *£tr. HSLT^fcutf, ££WEIWft3llt 
Wli. U«co4K>h ■ ?4 7£^UXT?-tZfflW¥f 

■r srsa&r ft i £ <> wc* ft . 

[ 0 0 3 8 3 4fc, i iOEtttftlOfcWtt. APIC 

[00391 ?5-fTyh0)Sii. Effctfttr-y^a^ 
£3rt-ft*rti*>Stt. &H?>ttM. -f^hflHMI. >f 

[00401 **Wt £ ftfl&OA Pitt, ^HWrft A 

pi«a«str£tMfcifc9f#ft. max. api«, 

1\ "canjubscribe"^— f-y (^ffSffTtt/W-f-^) 
itTcaiLPublish^^y (j»Wikf^ 
trifctftfiU*. 4fc. APltt. i>t>4<ybw* 

4KyhS&$kltzfrlz^Xcr>timzm-. "get.cur 
rent.envelope'VU-f-y (JjgXi^D— 7T5W&/I'— f" 

>-) fcfctr. C»*-fy|i, 3-;wW 

<o»a~^s*ift) . mm. v7z?54JWf>z>4 

Oh*%mit:i%£. 3-/W<*?#H£3-;kr 
ft. 09tt, *>ft>f<yb(C*frft, iKo-7'f 

[00411 *>ft W'J >y^-v4fdi-9-yx^7-f 

k*. 5fcC»£icoivc»tjilM<*yh -^-y^- 7r 

-Ffc*4*ft. U:#-?t\ KOWCtt. ^7*'J«y^ 
+14. Medarier<i<yb0>&&WT 9 

ft. 4fc. JKSKi-f^yhJi^n^f-ytJi^AP i;u 
-*yt. CLcwMTrry^-^a^fcyy^-fft. 

owe a, jar^wft. 

[00421 -B^y\j v y^)\f\,zA yxb—^L 
*>ft. IDLfcsy^fyl/^ftifcfcio'rf&ftSJ'ifc 



fct>wc7*Tyx?K ioT^SiiTv^ft . 

[00431 S3^r>y7"302tZ*-r«J:ot;, /*7* 

u-y^tt. t-f. tti0%RS*iTvift'i7'£. **i 

&**-ftfc*fc«i#W> rj£^j fclfffl-Tft?) 

1*1 j &&bU ^ru-z^^tw^r^^yhs- 
4«ILJ:5kL-C^ft*»Sr^7*t:fii«. *-f-y7*3 0 
2£&lvrs\7°f3Uar*-ftfctf>C. ^'J'/ytli E 
£A7*fc4 VXh-zH/C** (B2#!8) 

W t*>* n. -o>r O 

[0 0441 X-f'y7*3 04tCt3V^T. ^ij 7 yt« 
A *y b *£&tmmtfi< ft £ Tfflttft . .BBOffl 

ic^tftidt:. 'rry-ySz+fcioTtt. H41"ftft 

fc#-f^>'ht4» , tftt»Ot*ft. ilWV^Uv^ 
tt» 1B1EI^)J:3{C. *UetfcWJBI4T»t>. 
fK;*^<7)>f<yNS-^T^-fft. fflitf. »1«> 

AfcWjLfcfcStt^on, -f^hS-^fftio 
ttTi J:v\ *2^t7*y •y^-v{iB#ia§t:|ii-^'f 

ro-f^yhfe^i-ftidKLTfcJ:^. -fl/^y 

•yis'rtfj KybZft&'f&Zbt&feUzKt,, 

^■fft (^v7 , 3 0 6^*J^T) . 
[00451 X-f>y7*308£fclvC. /V/Vvts* 

<KH*ftCk(:-rft. Xf7/3 lOlcfc^T, 

nmcoj'<>bimm-tz. cm%. zzizimtz 
mtmxu. jKybnmmt&ohWh^sT 

<TJiH'<>b<7)®mi>&%?&. ) 

[0046] ^r«yr312^t>^T. A^'J-yxtli 

$lJ«tt^r-yT3 0 4tMft. +lh-T^I=^, ^ 
•f yT3 1 4(;i3^T. ^°7*y v^li'\7**»fe*na 
ttfcSfflU Hff^^jt-Tft. ffi«4/N7l*iK:«»$ 

<i. wyv^3&»**i<>tf!)-f<yh*iiffUj^fi"r« 

R*flBIW-«IBt:«M!fc**. i*itov»Ttt. EtTC 
K«JW«. E8»LTV»4W6«. H-M7*fc:iH!lSfiTV^ 
ftfBl0^7*y y^Ti,, H30Xf-yTi:tt*H«fc|| 
fWftifcfcWT**. 

[0047] -t7*^^9-f^^i. &&W<>yb • 9 A 
T0)4<y btzW&ffd. m4li. mi<W7W? 

jjw. v7*?74><<mm<Dmzm?i7~i-zxT>y7- 

J:ft7D- ^-v-hT'fcft. U-7";*?54<rtli. 4 



(8) 



HBPPl 0-27121 



[0048] Xfy7°4 0 2fc^jrf «fco£, *T7X9v 

^^T^fcLTSirfs. act. 
«. ^fcattwtfcfcsw-M^yh • ?47\,zn 

[00 4 9] XrvrAOAlZ&WX. QrHfylZtti, 
A7WAKyhi%{iUzkmilt:bZ\fr^X'i>. 

A^tlJoTjtSijSflS. 3-;W<-y?<97:i— "?>y r- 

tf)#Jifc-fS.ri:#TS&. Witf. M4<7)XtvT4 
0 6fc*sirvc, n-;WN*>y^#HI(i. 

/* 

*publ i sh. c 
*/ 

# include <; nexus. h>; 
#include "nxs_output/order_nxs. h" 
int raainO 
{ 

SalesOrder *event; 

nxsClientlD id; 

nxsPublicationID pub.id; 

/* Register the Client and the publication */ 

nxsCreateClient ("order publisher", NULL, NULL , 0, 8; id); 

nxsRegisterPubli cation (id, "order.advertisement", 8;pub_id); 

/* Create the event */ 

event = nxsCreateJSalesOrderO; 

event->; customer _name = "Jin Nexus"; 

event->;customer_address.street = "12345 Anistreet"; 

event->;customer_address.city = "Mountain View"; 

event- >; customer_address. state = "CA"; 

event- >; customer_address.zip = "95000"; 

/* Publish Event */ 

nxsPublish_SalesOrder (id, pub.id, event, 0,0) ; 
/* Clean up */ 



X^h&947<T>4^Vh\znLX%mL%\Wl£+{:t> 
£ a-frrtv 9%mn*XA UWBfca bf-i" h£ 

[0050] *rfx9?4i%t^ m *$±ttmw 
<&txmm? ur-y 74 08 £#$) . imzti 

&£Vvt3-;|,r(v?#j|(££fft-*. Xr>y 7*4 08 

*tLmz^7fr$,mmi. m*+&t*. 
ywzmt&zkizzix. «w+fc» imwo 
bz%mtzzti>-Bimx'$>&. 0*3*^ h-a 

f 7t mmmz. 7*$mth i t «. wc* 

[0051] ar<oMtt. crn/5s y^wiS-c^a* 

[0052] 
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nxsDestroy_SalesOrder (event) ; 

/* Unregister the publication and client */ 

nxsUnregisterPublication (id,pub_id); 

nxsDestroyClient (id); 

return (0); 



/* 



* subscribe. c 
*/ 

#include <; nexus. h >; 

#include "nxs.output/order.nxs.h" 

/* Callback function to be called when each event is received */ 
void event.cal lback ( 

nxsClientID id, 

nxsSubscription sub.id, 

nsxULong seq_num_high, 

nsxULong seq_numJow, 

SalesOrder *the_event, 

void *client_data) 

{ 

char *st; 

printf ("Event received! \n") ; 

st = nxsStringify_SalesOrder(the_event) ; 

printf(st); 

free(st) ; 

> 

int main(int argc, char **argv) 
{ 

Sales Order *event; 

nxsClient ID id; 

nxsSubscription ID sub.id; 

/* Register Client and subscription */ 

/* (Only subscribe to specific ZIP codes) */ 

nxsCreateClient ("order subscriber", NULL, NULL, 0,&;id); 

nxsRegisterSubscription SalesOrder(id, 

M customer.address.zip =95000", 
event.callback, NULL&;sub_id); 

/* Main loop */ 
nxsMainLoop(id) ; 

/* Unregister subscription and client */ 
nxsUnregister Subscription(id.sub.id) ; 
nxsDestroyCl i ent ( i d) ; 
return (0); 

> 

[00 5 3] I I I. >\7 Ufi&) 8R|a71 0 8, 1 14fc. *LTOfiDfflSLk 

HlW\yi08, 1 14. ^LTSHRilCEH m 04C««3ivO>4. it:. a/10 6(1 

i-mmmttzmmw^b^xmmnffi&ZGi- o^mr sfit&s 3 0. wtjA r> v 

^71 06Ji. *y hV-71 20*atT (it: »M=IJW-*fl»B5 3 
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2. a XT/* *ta- j^ybmizm-t&tfms 3 6 

[00 5 4] 1 0 6^^T^A*fc il^A/ 1 0 

e^^^-ccoai^JiS^j^iir^s. mwr. asm 

7*1 0 8iJj:tfifr;*?5-f 0 2*»£>A7*1 0 6fc 
ioTSaiSfufc-f^yMi, A7*l 0 6**-Hi<!>£*!i 

5 04 <7)*tz. 4 h^ffi^Ifc:te#i$*i*> . K(c 
fl&OfflfcLT. ^ri0 6#]IIR/\yi 14i5J:tW 
X?7>fA*i04£j*M'^Mi. at*i 0 6***1 

-dfj.-5 0 6, 5 0 8O«KM^h?)ffi&£Jtaa 

mux. mnmfrzmiwrtiifzte^tjy-r 
? * a yowrcii. s^-c* * . av u * x-v^ji 

[00 5 5] H5Ht/V710 6rt»*>. JSTC* 

•y?5 1 0. 4KV\>*g®Juv7 5 1 2, TUTo-t 
•yfr- 7*a??5 14. fSWT'n.^5 16. v-yf- 
7*n >y ? 5 1 8. itmi^aro y 7 5 2 OT'fc 

it. mtAim. mr. m. am. axv^mx 

^n-y^5 14ti. xy^o-rfpg£73-f^yh^ia 
A7V)**yt'&6. ^y^-- 7*0-y?5 18Ji. gffi 
ting) £H UT JSlTKa^i «k o %l5mX'4<y b ■ 7 
^yh^iitti-fS. iSH^S^n>y^5 2 0ii. yXf 
[00 5 6] H8li. laicOA^l 0 60^^1/69 0 



! = 
> 

>=. < = 



Mm 

J2LL 



>-X b-JU2tifzfc£<7)f—7Jl> 7 0 0. 5 
-f 3 0 . fi»«fJW&3M>T-7>7 

6 0 . feitXgiiar^^ fitor-y'tH 7 0 *atr. T 
-rPte. A7y . y ^A>fc±t^7*x?7^A*#[22. H 
3. *JJ:VH4^«'«flDXT-yr*SWft*IBt:. JilT 

[0 0 57] B2mf772 0 2lt ^Ab-/^ 
*/££-r-7>7 0 0cnx.y b U £*Sfc-t. 
[00 58] [3 3 *5 J: #04 tf)X-f-y 7* 3 0 2. 40 2 
li. gfiaw^^r^h -y— 7fVl 3 0 <?)3LybV 
£?f£-f . JL— f &7 < —}V F 7 3 4 JJilAx— If • vt 
• 7 -f K 7 3 6 «N U L Lfl*r*-f& i: . 

r i d * i t * z t *«r * 

3 7*»J:tff-»J bU*74 0«. NULL 

if. "call-back-on-any-thread" ( V^-fil^XU «y K 

•y ^^^^r^U >y h Z. 1 5r^"f . 

[00 59] 03tf>Xr77 , 3O2*>. fttKaf*4»f 
-7*/W7 6 0 tf)xy h y ^^"f . 
[0060] J£§£7 6 4«i. A^C^f b-JUZtl 
tztimcOZfcX'b S . H4 mf -y r 4 0 4 1 . SSSr 
K^toT-^iVl 7 0 oxy h y S-JS^-T. -f 
^774 fcoV^rttWTni 1 4 . 3-/W< -y ^#IS^ 

^7*^^7>fA'rttc (c APncio-c) ^ 
$s>Xoiz?&. mziiztffflit. fwrry^s 

y (subscr i bi ng appl i cati on) (3 i: i X Wfctffo 4 . 
[0061] WTcOfHTti. V7Z?74rtmm% 

mi-z>tzi,zffi&iim%®«%?'iT<r)m7<>i,?iz 

4 KM. i^tfjJ&hl^ybvimiXzy 

vs. h&mmt-mLw^ybnx-zyy'AfyjK 

mgUti-ZtzfrMU-l-yiZJUJ-fb LXV7A 
9 vAKt^ntz^<n%^m (expression string) t L 

xmfcztiz. zz£.$sm-&mtiismizmsfi»7< 
)\s?iznt&j£<?>i&nni'yf v7z&. arm*) 
x-3>&. (am. ^-rtKommisyf ytztm^ 

[0062] 

-kx<nm*?'(7 

±x<r>m*?4 7' 
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and 

or 

not 



[00 6 31 4*yh«tt*ii. 4*y\>nm£0>7 4 

7 • J 4 —)V H ( «Jtrta5^^7 <r H ) (4, H <y 
hStlSWot notation) tfflV»T*8J&f 4. «fH2, C7 

BP* 4 ^enumerated type) ft 6 Z. t fc WT* 

r-fy/(event routing) tf>|IH£ffi$ft..&. <r*lteo^ 
Tli, J31TCH9 fcl* LH 1 3 fc»lf*»tTBMBf * , 
WJc*fUr#rt*7^;U^*BJW-*flHWi. 08O 
7<-*K7 7 4W«lfr&h.4. 
[00 64] 06(4, 05^7*1 0 60** mctS**} 

r-^flliilrJKg-fS. ,I£fc£iW-*-f ;'7 ,, J;<yf■ 
-S's y(4, #ffcM*7>'x? r- • tfM&mtt 

14, 06^r-*«3I#x*rAFfy9£j££Ha$U 
Xr>y7\ ;b±tfH70f f -*;|ia*fflvvCA7TB'C>r 

hi 2ii, T-tmmtitzT-mmv-mz* 

[00 6 51 ^7*10 6 < r^^-fryh -^j ) 
(4, i^rx^7>f A'Tj>4^A7'^#^5'fTyh 

( t9H7>Ys 684fcJ:lXrsj 695£J:-5-C 

I^N^Aj 6 9 6fcJ:tf rjfiKysT'Bj 69 7) 

-f , • *7>*x* hfcfctf. SiATli, -ecOafiB? 

A7^m*7Vx*b$ii»La»t4. mtTVx 

{4. "mycost"tJj:tX"theircost"i:V^ 2-000'M'f 6 
a* htt****. >cost"(48A7>£iffl*$A7*(;:1i 
«fciS*3.X "theircost"J4, j£BIa7> 

t>m>^7tZim*&h3Xh*$li>t. "their cost" 
(4, KTTIIWIi* *J:3fc, ISB*«^4fcJ&fc:Jflv* 

hei rcost"TM ^ OS£i£ (del i ver) ifflU? 4 . "nyc 

ost-(4, SKy^ta&TflwtaifcfcfcfcL «a 

*>3*K *£(4*Ofl&0$><o^4&^&3Xh£fU5 
•Mi:#f£4. 



[0066] A7*l 06(4, 5/*f*ICfiilS*l'0»* 
#&firfcOWC ("RemoteAd") XrVxthZSts (fiP 
*>, &fH-4£l6ltt. 020^^7*2 0 2^18) . # 
RenioteAdtfTVx^hte, 1 Oja±«)"M&urce":t7V 
x^hfcmUrf. #AdSource^-7'>''x^h(4. «/N7* 
, ti&WW >y J'*jM^*A7*fcOIBI*>>'«(p 
ath)£|S;bt. #Adsource:t7Vx:? Mi, <eOj££<-D 
'J >y A^v<x(C# ? 3* r- Zmrth . 
LfctfoT, #AdSourcefcSttl, r 3.*hj ffii, 4* 
yh**wv-**fc^\70ifi»A7***C, 

[0067] #AdSource^-7*i/'x ? Mi. N£t* r x 

• sfrTVx? h j (sink object) <0 'J X hSrWf 
4. (SinkCafcJ:tfSinkNb(4, $i-0»J* MCftgftft 

v\ ) • *tvx* Mi, niia-rs^o'j^ 

h$Ht&. «£tf, SinkCa(4, Ren»teAd5 1 0<T>ti& 
iz—Wctl. ?y47>Y(>9A<7>k=f'mw)xY5 0 
5iGtl. RK(C, SinkNbte, RenoteAd 5 1 0^/SS 

[0 0 68]&jSB(M-7*i''x?H4, / VJ-y^kS 
^j£H5r7*i;x ^ h b Oltl^A'XCov^-CAdSources 
*ft U^-f AdSourceRef \)Zbt:1ttl. ZtlbOfflS 

(4, JaTTKWftidfc:, Aynrrcs/^-f a • K> 
[0 0 69] iv. /s-mtztsviKyvnnr-?-! 

mi 1(4, Hl^7*l 06, 108. 1 14*<BI6*> 

T-^fltJt(c^ffifi»iS(ciiff-r4^T-yropiffl«-^ 

«. • 9A7* IK*, ^-f^/. fftfC 

^A(4. *HflfflSO-^T'J)0, i^¥&CJ:0*li(C 

i>-k£ti&i><7)b?&tf. zzizimt&mmmzb^ 

[0 0 70] mi lfcfcWC, 7D--ft-hrtW 
(4, /N7***S^(2a/^f' A • -f^^h^iMffiL^W * 

#A7i4. ^waa^NrA^iiaw^fefttei-ifiR* 

7'^x^h?:^-r5 (H64H8) . Ar. y ri0 04 
(cftv^T, A7*(4Sv^c^rA • ^^h^jtajL, 
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it. ^x^Kyh^m-oxx^izi&m&'th. z<n 

h. ^7771 OOSiZH^X. A^U y W£i£«|§ 

5. iUn^A^^XrA • >f<y h"NSX_SYS 

_EVENT_CREATE_NEW_ADVERTISEMENT{i:, A7CfcV^, R 
eroteAdtfr^'x?!* (06#SD . 

[007 1 3 Xr-yTl 0 0 8£:fcVvC, ^y 7 ^ 

1" & . ( WfA • -< <y h "NXS_SYS_EVEm , _NEW.ROUTE 
S"£«fc 0 . A7flCA<iSource*:^x? hfcfl^*-* 

^feiitXr h 'J , frfctfl£4 hSrA-ru y £^a 

^4>^Ayi-c'^aj-r-si^t3*^sgffl^^tf, >-x 
Sag-fa. #Artn ^^i* { -!-^A^A.<7)gi!jco|gK 

T*£>l>*§£\ n-#;U- ?5>f7yh£?-x-y?U 
ftfc?)-gc£il^3> (Z<7)Wift<7y&%. "NEW_SUBSCRIPT 
I0N"^^rA • -f ^yhi)K "NEW_R0in , ES"WjMtii7Ci^ 

it. *tl&8ft%tU&\7s ^A7'(oroginating hu 

£*<i*fl#2#gOj£KT-&9, iWtfeO 

[00 7 2] ^7-/71 0 1 OtZiS^X. hh^X? 

tS^MfcHt*. (^fA • J<y h"NXS_SYS_E 
VENT_NEW_SUBS01I PT IONS" it . ffi^> A7 fcfft £iM£i}-f 
*. H6#Bg) . I^iy^fA • -T^y hHMUfcA 

OV^OReinoteAd£ft;i£. S'J'-nX hWttfclW & 
AdSourcefiO-I fc * , ^AdSource^O&fc. RemoteAdJi, 3g 
AdSourcetfE*., Neighbor:* TVx? hOi^y? • Ji'T' 

. mz. isyftfi. =m*7 s J*9 hizm-^subs 

criptionRef X> h V (MU$. 5 0 5, 5 1 2 ) £31 



[00733 Z.0fHh<m<?»s7'\<m&it. *^Bjc7) 

iOiMtti, AVU'x^fc^^^^-fA'i:^) 

[0074 3 01 211, VfAtWW^frWr 
U -y^^OA^^i^ii^^j^^^ 01 2<i 

5*}9»\fA.. B. C, D, Efcjjrt. y^AKtt;^ 

AS0«88R3*vo**. :<^tit Stttttt* r lj 
*>3Xh£#t*. U:#r>T. W*Hf. A^AfcilX 

[00753 01 2it. 01 lO^r-yn 0 1 0O& 

i*J:lOTW^71S|fc:*MR$*U RemoteAd, AdSource. 
Neighbor, fcit^AdsourceRef^y^'x^ h^#A7" 

[0 0 76 3 vltfOfifllTJi, ■9-7 r X?7>fA's#A7'c± 

IMILfci: AycjJK^^^'x^ h 1 1 0 

TyhX'bhZbttLX^h) . mz. A^Cii, 
rff^^^rA • 4Kyhj ( ) i 

4>^cry y v-v • '\7AtX'0)3Zbtf r l j $:tf>T\ 
^rcJ«^S;y\rBtaflW-4. /NrB*^Srgtt 

a'^a^C ST'iH^tfC*!. c: ^^-r. 
[00773 A/Bli, >f ^y 

fm&mtz. *Mxu. a7aa^a7bm?)3a 
r o j X'*>z<nx\ Httittm&vfKii&fct 

7 Vs.? Yizm&iitz^mvvs.tY iio6$-^ 
jfiu ^mt'^BtxMmsimx'&zzbimt. a 

[00783 -50 1 20T-*ffijt#58±§Jx£ fc . 
M 106, 1 104, 1 102tJ:->Tje«S*lfc-'t 

[007 93 H13J4, HlW^#. d^Lfc-f^ 
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ZrvTlt. 1) ttiUmz&mtiX^h'W vis 
■>cfrt><?>4<>bt:%mLt:J\7 (Xf vTl 20 
2) . £*:I42) ffltor>'\7frt>04'<>>hZ&mit: 
>\7 (ZtvTI 203) IzXnXmjZtlZ. 01 3 

[0080] &\7*#t*lfc:tt8e3*VC V**rC7*'J v is 
-vWlo*»^-f^hfc«lf-4k (Xr-/ri2 0 
2) „ ^^r'J7Dt7t5 14(4, SUltw rxy 

4) . J^yb • i^n-^t-^'/ffcoot 

®9izmLmxvTX'mm-h. rvru-ty^ 

5 14(4, ^3XT>yTl 2 0 4(C*iV^T. £<9>e<.y 

h^^yb ■ f-frtf^yizgHtZtix^h^i)^ 
mt&. %.mtix\w j mi. >*7v 

XtvTI 2 0 6fciJVvc, ;s7*(4-e-<9>e<.yt>£, 

m*:^ ■xy<D-r<oas 

[ 0 0 8 1] W^tf&W^frhJ b U: 
i§£ (XT771203) . ifi»A7*tt**>-f*>'h 

[00 82 3 Xf771 2 0 8fc*Hvt. Wvf0>7 4 
)V95 1 8#, SRat**)*** 'Oh • 
-COhfcKDiW. <Kfc. 7-f/P:?5 1 8(4, 

4-/H**itMH**. Xf771 2 1 Ofcfclvf, 7 4 
/P* 5 1814, *-f<^ - ro-y^t-f^hfcjD 

7uv7£%m7vv?iz1inz.h. 2m)V-T4>? 

• COy btMl 0(C*jrf. 

[00 83] Xr>y7*l 2 1 2tc*JWt. 8A7*(4. K 
£*>MSource£>&&* -f <y h tl?&l>#* &£T<W7* 

MSr£§jh*>S. .1*1(4. &\7bV7X954 

ffl(4. -BAdSourceT-*ffi£a>m$ftfc£^ Si* 
flU4ff*>*V^i:ta«S*U:V^) . AdSource*7>*x 

urceRefUXhtJIBW* M'O htf)SR"7>63|e 
. Xf-/71 2 1 6-1 2 2 2(4. loJ2Lb*> 
1f7*x? 54 A^<yh -Xr-yri 21 

6-1 2 2 2*4, AdSource(;B§^"ri>#^y^ • *7*J 



x^h«MC|irf$il«. Urtf^T, Af771 2 1 6 

-l 2 2 2(4. vmatitz* 47v>4 ^yv*%mh 

[0084] Afv71 21 6fc*NVC, 4 "Oh Oft 

Miybitmmi. zm±w^tz£^xmmzti 

*H {X^v71 2 18). -eoffetfD^ Xf771 
2 2 0fc*SWt, 74/1^5 18(4. -f'Ohj&MfT* 

-9-7X994'^ 4<>bf 
47iZ^lti^MX\ W&7 4fr**fSI&LX\i\l 
<H80)7<{-;H«7 7 4*#fii> . Witf. *>&-?7* 
*?9-f o^y^xfcftA/t'V^X h 

&*. t7x; 5-f A'^UiEi^IS:^ ^ 
*-f£*S£. ;^f-/7*l 2 2 2fciilvC'f"Oh(4ir7' 

(W7*/H'«reLfc*nKtt* t ** (*>S^(4. 

V7X 9 y 4 ^ x h v*<tt^"C•v > £ n-9-yHf 
^1 esEventO£fg*a* ft£ L » SI 2 O^T** ^ 5 -f 
ijxy^ii^^x^h^vy^yyx^t^aXv&i 

^^MiWiwr^^^-f^fcii-**-***, »2 

«0-f7*X 9 7 -f ^'t J4-S UtV \ 
[0085] 771 2 2 2H$JVVC» 7^;U^51 
8(4. -aU^rx^^-fA't-fOhSrjMffitS. 
*T7X9*H)<\t. W^7cr)?y4T>bXhhZti> 

-e^^-f^>-h(4®^t7'x^5'f^jsaj$ 

1&7X9 y 4 tMF%M>K7\zMm%1xX v^*«*. 
^N7*(4'f<yh*-e<0i£|^N7'(3MmfS (i^n 
-7-C07 ^ -;l/K8 0 2a>£f<J6fFLT, -e<^)ig|^^7'*< 

r-f y/- 7*ny?*MW*4. 01O#Bg) . 
[00863 £ £Ciemt£HStfflT'(4. 3Sa7*(4. jS 

fcj^oT, 06Of*Dt7^'x ^ h 6 5 1 *M <* h b 

-&tt:m£. b Zi&w^7Bizmm?z>. 

^m7iSx?b6 5 2i > ^co4<ybt-fctm 

2aPMN7*B(C2[IIB^)>f^haffltffd*W*Sr 
\\ fflli'^7BtfZ<r)4 ObZ%mt&t » Cliti.ll 
1 3cr>XT«/7*miL. Z<n9y47Vb<r)*r7X9 
y A )V>\ Kybb -Set* iWf 
4. 
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[0087] 09 (2. 

flLfc>f^yM;:xy<a-7 , £iD;lS. 
(2. #-«yhfc:frtlL, jg£^8 0 2, JE#fe80 
4. ^r»Jv^*80 6, 7^^808. W8i* 
^■^7810, #^^[3812. fiBfeS81 
4. 77^8 16. t><tl^gjai^El7^-^H8 2 2i 

*tr. 75^(2. C£(:ie»?Sltt*{&J-e(2. mt% 
\>\ JMoWIWCtt, 77^(2. 0fl*.(2\ -f<5^*« 

[00883 HI 0(2. 4KVY?)2*o<n}V— : r4 V? 
■ 7n v 7 ?>y hfflfcjjct. #yN7*(2. Ztitf 

7*n.y?£iajot£. API12, -^yr-j&'&SirT'X 

ff$8£ get_current_route_info;l^— f-y t#tj . 

;l—r y^t»®(2. &Wffl^7mz 1 ooxy h y 

CJ:^T>f^:^fc*aHdW9ST«l4. 64t*^ 
[00 89 3 V. r'J h'J 

U JfcS^Eg$J'IWJgi|^x(direct physical connect 
ivity)fc8tfo(t*«fcKUP5rK ££(;:fe®-r£|IS6ffl 
1 r U h 'J rt^N7li^T«^t«K**lT 

'J rt*) 2 oo/NTTBfctt, i flx U h U £8ifl6#g& 

<. n«a^«^i^&«<. mz^K^frnm&m 

ffmtM-cu. Tyhy<o»»WHEU u*w 
•tfttv y h y (2-Ht^sif- y h y *w <y hm 

yhy** s *-*J:3lcaiiH*ff$£i:a'fc'K iii^ 

[00 9 03 lowvra. io*>^y hywwciw- 
a.rfca'Siu*. ^7>fr>h urrvvifr&i&t 
•vyxtyjrt) w\f\i&mtt>k.% * Wry r-y 

yhy-Oi, 4<yh. Witt. SalseOrder*>»fo&*B 

mzztna&ttw zztztR&timm&i. # 



[00911 SQ*>iatW«i. ^Sr y r- y >\7#&Bl 

7*-77 M=OHT£SU ^H-r'J r-'J (joint ter 
ritory) £i55&t6 i tifiX'Z h. T ] J h yffi$i(2l££ 

co-sh Lz&ftztL&cox'. 2oco^a$-«t^-rs^ 

7*12. ;<0ft|Slry hV0M*>hto**ms&tl. z 
*i(::ovvc(2, -i ho/P-f < wwmmxvx 

[00921 VI. f-^^SM (database con 
nectivity) 

HI 412. Hltf)*? 20fcUB»a4*ifef 

• rry^-^ 3 yi 30 2^)7*0 -y^ia 

T-^<-X • T7-yy-^ 3 yi 3 0 212. 

-f y^-7 x-x • tv-+> 1304 s-^r-f Sr-^^ 
-x ■ ?4 75 u ^-s-^. a-if*<T-^ • 1 3 

-XI 3 0 8(2. 3j-9^;K0racle). Hf^^- 

X(Sybase). 4^{2>f V7t$7 ^X (Informix) T'fm 
$^T- ^ • ^-X t?Z>Zk & . *%BJ(i % 

[0093]H14(2. h5yf^y 3 y-t-^13 
06i#tf. h5y-f^^3>-- t-^13 0612. h 
• 3— jtfl^— ^aydransarc Corporation) 
**!8it-r*xy^-^ • h^yif^^ay • ^-^(Enc 
ina transaction monitorJTftl) <I btflfrt. LV>. 4 
fc. M^-tf. 7 <;KNovel 1 ) ^Jt-ri, 7 ^ -fe h' • h7 
l^if^i^a y • ^E— ? (Tuxedo transaction monitor) b 

*C**. r-? • ^-X • 7-fy7'J 1 304£3Tf5 
r-^ • ^-X^gggB 1 3 1 012. *••/ hV-^ 120 
fcga&U *>y 1 2 OfcOr-^iSSfiHT 

3. T-i? • ^-Xft&SBl 3 1 0(2. A7'18tl$"'^f 
•ri, y 7 h ^xrS-^^'t i < . *>£ W2SH10A7* 
(C^L-Cfe«tv\ Hl4(2tJV^-C. T-i? • K-X ■ 
TTVfr-*/a>1 3 0 2\tT-f • K-X 1 3 0 8 (C 
tSfRSriHifJ-TS. r-^ ■ • T7*y7--y3yi 
3 0 2 1 . f-^ • ^-X 1 3 0 8frt><7Mmm# 

[ 0 0 9 4 1 r-* • ^-X^S5 1 3 1 0 (2. A^y 
■y^-v. ir7 r X?7>f;N*. 4^(2^fc-rS^i:*''C*§ 
S. r-^ • ^-xmffittl 3 1 03&*^C7*y y^A-T* 
Si§£. 0Ui(f . x-^ • ^-X 1 3 0 2£ftlrVttlK> 

aaiw^iaiawT-f o r- *&m. l . ^^^m 

t l>*imX'h&. T—9 ■ ^-X 1 3 0 2#^7*X?7 
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-X 1 3 0 2 ftKJSIfrtft . £ ; Cfett-tft&SfcMU:. 
• ^-X&^Bl 3 1 0m<7)a>7 J^x-ls-is 

3 y • 7r4/U (05^-f ) £-&tf. 3^7^al/- 

^ 3 y • 7tjm±. mm. ir-9^.-xwm^7 

-fft. 3y7^iV-ya>' 7r4M±. m 

m. texv/tttiitfrt** 4 <yh<r> 

li, t-* 13 08OWT'7 r-£W-fftffi*8 

tfltsrrft. 

[00 9 5] 01 5ii. r-? -*<-Xtf*r7x1v4 

fohb^izWnzixhxf-^tt-tyu- • ?-v 

-M4 0 0T-&ft. mm. *-y r-7-71 20*^ 

it— 9 ■ k-x i 3 o 2t;iiJn$iis. 7a- • f-^- 

M 4 0 Oii. ■ ^-^it&gfll 3 1 OjMRC* 

^-C&ftfc&S-fft. *T-yT14 0 2fc:fclvCT-? 

• ^-xmm 1 3 1 o aw <y v *%mt& t . r- 

? -<-*l 3 0 6rtfc-?«y7U8*frfft. T-fifiT 
-9 ■ K-ZMzg&tZtmZtL&fClt. 

&t-9 ■ <-Mzii r%V?Jh.t>tiX i 

IWU (commitment) tit. T-ltfm&Z^-? ■ < 

-*£A7J$fift£i:£Si*-rft. t- 9 

ft. Lfc^T. r ®tAiij SM^H^iiS^-C 

A.y?j (rolled back)-f ftdfr'T^ ; ■ h?y 

■f ? ^ 3 y SrK 0 jg-fc: fc ft . r o-;loK -y 9 j 

coo, H««itstt»^»t4T-^<«aetaBiES*i, 

£fift. ttffilCfcoTli. r-* • ^-X&*£&1 3 1 
Oli. *ft^yh£gfrfft2T-»J, r^ttAiij 3 

- [ 0 0 9 6 ] HI 6li. t-9 • *-*0WJ -y x-v 
T'fcft^£tl£ft£*iftAx-yr£^-f 7o- • f-Y- 

m 5 o ox-hh. mux. Hftm.—vipf—jrm. 

tn. Wm. &SlVBJEZt-9 • 1 3 0 2fcfcv^ 
TtHi:. 1 3 1 0(i*>y 1 2 0 

fcJSJHWfc'f h Sr^aj-r ft . *-r -y 7" 1 5 0 2 £Jd 
W£\ h^yf^ya^ ■ *-?l 3 0 6J2. r-* • 
^-A&^l 3 1 0# ry-Hj -CfcftdfccOji^ 
gttft. ^^XT'yT5rHfff ftjEffi^r^i. h?y 
if ?>- 3 y • t-^ 1 3 o eoSBt^fcj^Tlt&ft 

ft. *-f /ri 5 0 4fc*Hvc. firsft^J: r-* 

• *-*fSB«l 3 1 Ofi. *iig#tsJ:tf<e<0j££ 
(») 



[0 0 97] *r */ 71 5 0 6-1 5 1 2ti. mm. 
i-if^T-^ ■ ^-X l 3 0 8 K3Sg£JO;tfti§£fc 
Hff$iift^-f yT$^. xrvnsoeictjvvc 
r-^ • ^-X • h 5 y-f^ ^ a ytfmkt ft i: . r- 
* -*C-*1 3 08WU h7yf?y 3 v-t-^C 
Mi{f. X/Open<7)XATnhrJ;USrfflV^-r. h7 

3> -^-^1 3 0 6{±. t-? • ^-^S^l 3 1 
0H, h=y>-f?!sa>&mLlX^&Zk£m\L. 
T-9 • 1 3 1 0\tY=yy^r9 i" a 

B-tft. Xfv71 5 0 8CtJV^T. i-^r-^ • 

^-xK^iMD^fttf. a— f jase^sttTiLTi* 

[0 0 98] Xf7 7*1 5 0 7C*J^T. i— f (^^ 
{i. SSEfctoi-ftV^h^xr) h7Vf;y3y 
Ir^Ailft^ClfcSrf^-rfti:. Xx<yT15 10 
CfcWC CW^Kih^y^^ay • t-^l 3 0 
6K£ii$*lft. h^yif^xay • ^-^ 1 3 0 6(i 

t—9 ■ <-xmm®i 3 1 ofciiaiu ^fMi^ti 

tzr-9*T-9 K-Zl 3 0 8j&>^l§aiU C1<0 

^tAn^^T-^^t^f^yh^^-Tft. -f^ 

yhli^l 3(C^fJ:^t^$iift. ^r y 7*1 51 
2HfcV»TJ--1f (i^Ji, ^S5rjDi.ftV7h'7X 
T)tf. YyyWisByZu-fVrtvtthZtZft 

tfifht. zcowsthyy-ffi/zy • *-?i 3 0 

6H£^$^ft. b7yf^yHy t-^1306*« 
r-^ • 1 3 1 Ofcfggr-fft i: . r-^ • 

^-X&^gPl 3 1 0tt7,f77 1 5 0 6<7)£S£o^ 

t r B^j . 4<yh*&mi%\<\ zoxdiz. 
iztffit&mmte. ffifflr- 9 • <-*%kmizii-wt 

Wc%lfAtU$£Va-fr>< •/ 9 >mZ%mz}jiX ^ 
ft. 

[0099] S'JcDHMfflfcfc^T . MfflfftT-^ • * 
-X£jm» 1 3 0 2iP Yvy*f9 is* V • 
^V^. r-^ <-^l 3 0 8i:^-tfti:#(i. 

r-^ • 1 3 1 o#h7y-f?i'3 y • * 

-ft UrtMWft. Kfc. t-? ■ <-^if^i51 3 
10ti. Z<T)iy7 A*?3.\s-i/syX'\±. ^7*) vis 
*&£V/*tzm7x?y4*tLXi>fflfc?h. r 
• <-X 1 3 0 8(i. ZtitfZmkte?—? • ^~ 
Xfflmi 3 1 OHS^ix-CV^Tt. h^y-Ov'a 
y • t-^tc«S!$ii-CV^fti:#^ft. 

[ o i o o ] v 1 1 . 

W) xyf^f^, tt«?:^Lffi 

mi-imw r-9-7**?7>r>Kj xyf^f^^t 

tf. >n'7*D •yi'-vfc i tX-9-7*^^7'f>'^±, ^-yhV- 
^5rffltT5v^m$iiTV^ft. *vh*?-?l*. * 

KiMj ^-y hV-7X'h&. 
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[01013 *m<omommtte* momm 

tzWm b -Set* 4<yh lz=tm-& . V&ioXtf^tt 

[0 1 023 JJfi^+jMB^IdlWJi, l^#x • IsXt 

typedef struct nxsSystemEventHeader( 
nxsULong length; 

Byte length of the event 

nxsLong magicjiumber; 



mi. xry^*. wxmK* tMmxtt 
[01031 ; «: kbus uz*%ty<wmmnivmm 

&zb*m®'tzi>(?>x'S>&. 

[0 104]iUlti£tfA 
(44J0 

6. 0 y^fA • <<Ob 

S'.XtA • -f^^ r-flfiaWu include/nxs_syspac 
kP.hh?)4>Tl£&$*l&. 



Used to det 



ect bogus evnets 



Nexus version number 



Nexus version number 



nxsEventRouti ngEntry 



nxsUlong nexus_version; 



nxsULong routing_offset; 



nxsULong routing_offset; 



nxsULong sys_event_type; 



NXS_SYS_EVENT_* 

nxsULong data.off set 
String data 
} nxsSystemEventHeader; 
sys_event_type(7)fiHi, transport/hub/sysevent. hhO 
*X'M.~?li&ZbtfX'Z&. ^XVisATJ*- J^sh 
a&Sn-Kte. nexushub.hhtefcVvCmiSft (NexusHu 
b<7)jJ&bLX) . sysevent.cc£t3Vvt£|g§;h.3>. x 

yvm&ztvkx b u v ?x h s . *r&& \—7 v\m 

Ttf)jI9T&3>. string <;space>;tJj:tX<;nul>;J^|.^ 

/string/ A _</037) X iXm&tltl\(/037) £Rfc 

long «ftt*3 2tvM 

NXS_SYS_EVENT_CONNECT_HUB 
/string/ 
/string/ 
string 



ulong fir^rL3 2tVh<| 

(455) ? b&mitx b >j >rmtt&t 

tTTlSJ.* 7 -b—v 1 (peer-to-peer message) b iXfft^t* 
tih. Zh^^Kyblt. m<?»\7lZ\Z%.l%\\ flfe 

U h U ^5 7 (territory graph) . 1 

m>s'7frt 3 *tim\,z$m<7)4 <y y * r fc 



Sending hub name 
Sending hub territory 
Sending hub incoming EventQueue: : PushConsu 



mer 



ulong 



Receiving hub's cost 
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ulong 



Sending hub's cost 



.1 <7)A *\y hit „ NexusAdmi n : : HubAdmi n : : connectHub^ 

<?>a->\,c7>mmt Lxm.&zti&. mttimw^imiz 

Site>fctf>£. NeighbortJi^EventQueue^^t£LT*> 

IZ. WiWlZtZm. «. &ajfflA7littK. NexusA 
dmin: :HubAdmin: :connectHub / \£)T— 3f jl> V r* £jl t 
T , gflfUtf) A3fcEventQueue : : PushConsumer £ ^fr i~ & C 

(x 'Jh'JfcSIISLTl^) . -f'JMJtf) 

NXS SftS_EVENT_ CONNECT FAI LED 



W3?t& KSblzm^tlZ ( NX5_SYS_EVENT_REQUEST_EV 
ENTTYPEStJ i l^NXSJ5YS_EVENTJlE(lUEST_ADVERTISEMENr 

s> . y\r3fiflBKc^uM;^^<r**«&. 

&£NXS_SYS_EVENT JEW.ROUTESt £Ki*aj7Ctj*a}-f 
S. 3fIffi"7ttft(C. NXS_SYS_EVENT_REQUEST_ROUTES 

{i(iNXS_SYS_EVENT_CONNECT_FAILEDSri*S . 



/string/ Sending hub name 

/string/ Sending hub territory 

/string/ Reason for connection failure 

NXS_SYS_EVENT_DISCONNECT_HUB 

/string/ Sending hub name (or neighbor name) 

/string/ Sending hub territory 



NXS_SYS_EVENT_END_OF_STREAM 

/string/ Sending hub name 

/string/ Sending hub territory 

NXS_SYS_EVENT_REQUESTJBVENTTYPES 

/string/ Sending hub name 

/string/ Sending hub territory 

NXS_SYS.EVENT_NEW_EVENTTYPE_FILESSrfflV^T . j&fflfl 



&s£<l fcA 5 "CSS. NexusAdBin::HubAdmin: disconnect 
HubA^)3-/W)|S*i:LT. *<ii«cfci8&. 

A • >f / <.yb*^iajSil-S>. NXS_SYS_EVENT_FAILJ5UBSC 
RIPTIONS, NXSJ5YS_EVENTJ)ELETE_R0UTES, fc«fctf NXS 
_SYS_E VENT_DELETE_ADVERTI SEHENTS. - 1 
> YtffiSX&tlh t . NXS_SYS_EVENT_END_OF_STREAM# 

(4 6H) 4<yh • S^— ir^ti. NXS_SYS_EVENT_DI 
SCONNEQJlUB£gft Lfc&$^7±T'^-T£>l> . 

NXS_SYS_EVENT_NEW_EVENTTYPE_F I LES 

long Number of files F 

long Number of types T 

Repeated F times: 
/string/ .nexus file contents 

/string/ . ifr file contents 

Repeated T times: 
string Event type name 

IFRfc«fctfNexus£lFRKn-FU 4i4Wi-f^f <F>A ^>h£Jl/dfil$(neighbors)£B!HvT.\ 

• 94 7£imt&. 4<ybiz. mmjttsxvmz* mtix^imtzmi. 

NXS_SYS_EVENT_FORWARD_EVENTTYPE_FI LE 

ulong Address of EventTypeFile state 

long Number of event types T 

Repeated T times: 
string Event type name 

A<yb ■ 9 A? ■ yrAjmxx/A^yb ■ 7A7Z 

^x<7)mm^tix^imnzmmth. akvy-** 
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NXS_SYS JVENT JEQUBST J0)VERTI SEMBNTS 

/string/ Sending bub name 

/string/ Sending hub territory 

NXS.SVS_EVENT_NEW_AD VERT I SEMENTS £ flB I vt . jSJHWa 
NXS.SYS EVENT NEW. ADVERT I SEMENTS 



long 



Number of Advertisements A 



(4710 



Repeated A time 
Advertisement name 
Event type name 
Priority 
Storage mode; "p" or 



't" for persistent or 



Time to live (seconds) 
Originating hub name 
Originating hub territory 



■ A iy Mi*§«s*is . 

NIS.SYS_EVEKT JORf ARD JU)VERT I SEMENT 

string Advertisement name 



/string/ 
/string/ 

long 

string 

transient 

ulong 
/string/ 
/string/ 

MS_SYSJVENT.CONNBCTION.READY 

/string/ Sending hub name 

/string/ Sending hub territory 

mm^mmmi-hmtfxzx^h. 

T V NXSJSYS .EVENT.CONNECT ION.R 

NXS.SYS.E VENT.CH ANGE.ADVERT I SEMENT 
/string/ 
/string/ 
/string/ 
long 
string 

transient 

ulong 

-SW" &RemoteAd£ffi^ffiT'H#rt£o I^^fA 

NXS_SYS_EVENT_DELETE_ADVERTI SEMENT 

long Number of Advertisements A 

Repeated A times: 
/string/ Advertisement name 

/string/ Originating hub name 

/string/ Originating hub territory 

±VZ0>4<yhi:WktzJUv\7*m*X. 

MS_SYSJVENT.REQUESTJKHJTES 

/string/ Sending hub name 

/string/ Sending hub territory 

NXS.SYS.EVENT.NEW.ROUTESJrfflV^T, ^t»*-f < y 



Advertisement name 
Originating hub name 
Originating hub territory 
Priority 
Storage mode; "p" or "t" 



for persistent or 



Time to live 
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NXS.SYS.EVENT.NEW.ROUTES 

long Number of routes R 

Repeated R times: 
/string/ Advertisement name 

/string/ Originating hub name 

/string/ Originating hub territory 

long Cost 

NXS.SYS.EVENT.NEWJ0UTESOiliaHi^NXS.SYS.EV • >f 'O' Mi, tHfi^Oi&Tfc Wt£ i t & • 4 
ENT.NEW3UBSCRiPTlUNS^#^>fi5. «BKU. 

OWC. JSlHHfc&itSfl*. ISfttt. &aj7C. ffefl^ NXS.SYSJVEWT.C0NNECTI0N.READY^;cOifi^i3^aj 

V\ ^-h*memoteAd(l^1-^ik^gKTfc5 
NXS_SYS_EVENT_CHANGE_ROUTES 

long Number of route changes R 

/string/ Originating hub name 

/string/ Originating hub territory 

Repeated R times: 
/string/ Advertisement name 

long Cost 

tm<naxhi:$cmt h. -^SRemoteAdfcJt/Adso • JKyhlt* m&ittitXfZ0)4 ^> hfcHfc&fcifi 
urce£?UlU *conx hmZWm& . Z<M/AtJ> mm^X. 4X0£m>\7£mt>tll>. 
NXS_SYS_EVENT.DELETE_ROUTES 

long Number of routes R 

Repeated R times: 

(49H) 

/string/ Advertisement name 

/string/ Originating hub name 

/string/ Originating hub territory 

m4^££(RemoteAd) £&&(Adsource) fcfflSfc* ZtlK&Ufon&mmmizmiZilZ>1>\ fc&^CDWc 

&. ZtMMk. NXS_SYS_EVENT_FAIL_SUBSCRITIONS#>\ A • JKyMi, mi7CtS£V1MM'^7ai& Officii 

NXS_SYS_E VENT.CHANGE.CONNECT I ON 

/string/ Sending hub name 

/string/ Sending hub territory 

long Delta to sending hub's connection cost 

NXS.SYS_EVEWr.NEW.SUBSCRIPTIONS 

long Number of subscriptions S 

Repeated S times: 
/string/ Advertisement name 

/string/ Advertisement hub name 

/string/ Advertisement hub territory 

/string/ Filter expression 

luong Owner id in sender 

ulong Subscription id in sender 
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0-27 1 2 1 



fx 3. ^tt^^+fc^Kfrtf* NXS_SYS_EV 
ENT.FAIL_SUBSCRIPTI0NS3!^aj7Ctjg$tlS . 



mmm±.£ : mzfti8.L. wz^TRemoteAdce 

It. RemoteAdli, Neighborl;:ttLTSiiik£fM-r63S 
AdsourceCfc*.?, L&^*§£ ) . SinWi. * 

<7)^(CSttSSubscriptionRefSriUirr-5. 

NXS_SYS_EVENT_CANCEL_SUBSCRI PTI ONS 

long Number of subscriptions S 

Repeated S times: 
ulong Owner id in sender 

ulong Subscription id in sender 

(50H) VAh±&fifyW)iltt. Z0)<i<yh CioT, SinkJrEfr^-riSubscriptionRefCiS^ 

NXS_SYS_EVENT_FAIL_SUBSCRIPTIONS 



long 

ulong 

ulong 
/string/ 
/string/ 
/string/ 

NXS.SYS.EVENT_FORWAW).SDBSCRIPTIONS 

ulong Client id 

ulong Subscription id 

Srt -SRemoteAdUd <W*7fcOl vf fi£ 6 . #Remo 
teAdli, ^^T^M^L-CSinkSrffrSLfc. 
AdSourcetei.6 ( £ fc'^RtLTVVfrV . SinkJi 

i^^tC^&SubscriptiaiHrfSrfiJlrt - *. n-a 
^T'&V^RemoteAdfcfcf L"C . 31V — * £NXS_SYS_EVEN 
T _NEW_SDBSCRIPTIONS$-iMai-f h . 
NXS_SYS_EVENT_QELETEJVENTTYPE 

string Event type nane 

x. ^x^sm^iix^ii&mism^iii. 

[02] 01<OA7*_L<7>, 'Wvis+nXttTTV 

[03] Hl^V^U-y^*«-f^yhe:4»^&IBfe: 

[B4] HI wr^^-f'W-f^hfc^HW-ilB 
lZ$m-?hAT v~7*rtt7u- ■ f-v-K 



Number of failures S 
Repeated S times: 
Owner id in receiver 
Subscription id in receiver 
Hub name where failure occurred 
Territory where failure occurred 
Failure reason 

[H5 3 II 1 M\7<7)mWt:*i-7v y ?0. 
[063 M5<7)^7<r)**ViZtemtiZT-?m&Z 
?jr$"0. 

[07 3 mn^fmtowm*mt>t&. 

[083 A7W94 7ybfcovvcortBR«rlE**-* 

[09 3 -f^yhOxy^a-T* • t-?WM<7)7*- 

[01 0] >f^h^);U— -f-f yf- 7*o-y?tf)7*- 
-e>y h£Srf0. 

[011] H1^y/j^6<0t-*^(cS«*4B 
[012] T-^*»ttS*ufeEl6tfDr-^«Bft<0fif(t 

?5"f0. 

[0i 3i hioat***, ^^^vfwx 

7D- • f-^-h. 

[HI 4] HI*)** r-7-?lslB*&*itfc. t — 9 

[015] r-* • ^--XaW**?^?***:* 
£||*T$*i£*T>y7 , £*rf70-- • ?-v-K 
[016] t-* • V -y i^T&S fc & lz 

100 ♦•yh?— ^fiaylfa.-* • i'X-fA 
10 2, 110, 116 A^'J'yH 
104, 112, 118 lT7\X?5-f^ 
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106,108,1 14 i\f 
120 

13 0.140 -f'JMf 
506. 508 J^yb • ^fa- 
510 ?74T>Vm-fUv? 



512 >f^hfI/D7; 

5 14 7V rot «yf ■ 7u -y ? 

516 fSWT'n «y ? 

5 18 7*y* -^n 7 ; 

520 mfmfuv? 



mil 
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293 




(OV*$ IDUt «Ci& > 



, AdSflTlrftaU 



- ^sta ll in g a n Application ( P ubl i shei) on a 

1 I. .u 

I IUD 

©2 



[H15] 




■I 

11* 

■MflO 



61? 



[H9] 



802 — ^ 
804 

808-*^ 
808--^ 

810-^ 

812-^ 
814-^ 

816-^ 

818*^ 

820-^ 
822-*. 



Time ToUvo 



UttnfBuhKrfbtrPi.. 



ft* A 



(S3 ^ 



-EflMtJ© 



fi g . I ff - BQI5- 



(23) 



W10 



[®3] 



ass 



302 



Publis hing E vents 

g!3 



\ 



f«Qfstar puUfcaUoflS 
•Qaina a prt^riauitod 
•crvtrUsemam (Sip 
2(*)wmiftuo 

conncmd le tha 




306 



308 



.-310 

7 J C 




312 



33 B«J45v 7 



*Ufiregisterpat>Rc8Uon 1 



^314 

y *<kV Oi?1 TvL 



(24) 



#$¥10-27 121 



[04] 



400 



402 



subscriptions wtJIHiub 
connecte^to tftis 
su£sOT)er(a 
subscription can 



404 



T 



Tfl l l th e hub * to a lepfr 
subscriber whetr^n 
event occurafcie., 
ragfetep^Uback 
procedure for each 




Do SUflWtlUJjg 

with received 
"Movent 



1?3 



408 



Mannirlii 1 ■ !* »i 1 ■ 

unrcgisier cimiif uiki 
-subscription- 



S u bscri b in g-to-Events— 
-Figr4- 



(25) 



0-27 12 1 




(26) 



mffl^l 0-27 1 2 1 



me) 




(27) 



^1^10-27 121 



[08] 



700 



* — «■ 
^UlUI \ 

*l — - ^ 


Description 






-Priority 


TimtTo 

-Llvi' 















730 



- fi ^yif ****** s£^r»^ t^ iift nupt 

734 



Application" 


1 - . 

•Hum 






Twrtfcwy 




-40- 














3-D 



760 



- R^Ulw wJ pubfluilluna fa ihw ti ub 



iHTimi 
UIRMU 


II- 1,1 II 
1 III 1 ¥Q 




TD 


£5* 





770- 





Cu luni 

Pilttjr 

■Info (if cfty) 




-Subscription 




**1 







m 8 



(28) 



0-27 121 



[010] 



-Routing Blocks of an 
-Event- 



ra to 



[014] 




^fepM iM wi l ' 



^ij*. tf~ SWA- 



(29) 



«fBB¥1 0-27 121 



[HI 1] 



1002 



!004-^ 



OteribuU Iwtormitjnn 
About hub uumjcOo iti 
inumo,huM 
(Creairnitighbor 



-amonehuoa 



-Ceonecihub' 
Connect jonf*a«d 
Disconnect hub 
Connection ready 
C&aoge-eonnection 



-Requeseevef * t ype s" ^-k-go^v 

New event-types *fr «1?< 

Forwanf event type* 4<c*- 91> >fc£. 

D*fete-evem-types 4 9i> ft ft 



»\TflBt-Jtt3eu ->nt 
List x^<fcytor(?& > 



{GsuiftJUmottAds) 



Dtoifettrtn* 
about rauMS 



(Grata AdSourtus, 
AdSoupiRaf List 

/fats) 
(&0om j currant 
^rfsourceforesdi 
fUmoe«Ad (I—at coat 



Request advertisement 
New advertisements 
Forward^dwtiiement 
Chapge Advertisement 
QeJete-AeVertisement 



tmong hubs, 
{Crw tiokt) 
(Eidi tu/brpflsses 
subscription back 
f unoJosst cost pith to 



fL^ sua. 



•Request rootes" 
New routes 
Change routes 
ftalete-rotites 



~New~stzbs£riptiptfs~ 
Cancel sijbecnptions 
Fail, sub sen ptfons 
Forward -subecriptiofte- 



-Rgr+I 

Populating-Data Structures of Hubs- 

r& r. 



(31) 



0-27 121 



[013] 



H^IMtW^ Hit 



1202 

^-1203 



X>A'0* 



" 1210-^ 





(only for Wj 


«isera*r. 




enttttofsef 







mighborifiQ 

GOfYMCtOd 

subscriber ^nk otijeci 



have 




focdi* tending 
hub* that 
seen the 



(32) 



^^10-27121 



[Ml 6] 



1502. 



1504^ 



















< 


( Oft Ibtimt * Lt 3 s 









G3 ic 



Aft? 3 



■ V Ww mrw a u on ba tte r 

Wmai* 

1 00 oonntctof 



&*»». 



Unr m a lm c mivw hi I 




•MonkwjijlBawWeBnnwIar 
0 0 uJ i uailw 'puto' duU-fronH 



- OB la ^=9»=S^>yK.t.-teAS 

at*, 




(71) iii^A 597004720 

2550 Garcia Avenue, MS 
PAL1-521, Mountain V 
iew, Cal ifornia 94043- 
1100, United States of 
America 



(72) %ffi% 77ri/k/77f-3 

Vt&fc®*} U 7 */P-TiW95014, 

10461 

(72) S&BJ§# r 4 )V~7 V ■ XX- ti- V 

y* v*&m* y 7 ^-;u-r^95i3i, 
■*ry*-t,* J r?-7i'4x 1510 



(33) HHPP10-27121 

1. Title of Invention 

DATABASE NETWORK CONNECTIVITY PRODUCT 

2. Claims 

1. A method of connecting a data base to a publisher/subscriber 
network, so that the data base can publish events to the network, the 
method comprising the steps, performed by the data processing system, of: 

providing a link so that the data base can communicate with a 
data base connector computer program by way of a transaction monitor 
computer program; 

setting up the .data base connector as a publisher hub in the 
network; 

receiving input, by the data base, from a user that alters data in 
the data base; 

Informing the transaction monitor that the data has been altered; 

receiving input from the user indicating that the altered data 
should be committed; 

informing the transaction monitor that the altered data is 
committed; and 

sending, by the data base connector, in accordance with a message 
from the transaction monitor that the data is committed, a published event 
to the network in accordance with the altered data, 

2, The method of claim 1, further including the steps of: 

receiving input from the user indicating that the altered data 
should be rolled back; 
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informing the transaction monitor that the altered data is rolled 
back; and 

refraining, by the data base connector, from sending the altered 
data to the network in accordance with the rollback. 

3. A method of connecting a data base to a publisher/subscriber 
network, so that the data base can subscribe to events to the network, the 
method comprising the steps, performed by the data processing system, of: 

providing a link so that a data base connector computer program 
can communicate with the data base; 

setting up the data base connector as a subscriber hub in the 
network; 

receiving, by the data base connector, an event from the network; 
sending, by the data base connector, data in accordance with the 
received event to the data base; and 

committing, by the data base connector, the data in the data base. 

4. The method of claim 1, further comprising the step of: 

sending the event, by the data base connector, to one of its 
neighbor hubs, where a data structure in the data base connector indicates 
that the neighbor hub is on the least-cost path to a subscriber for the 
event 
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5. The method of claim 1, further comprising the steps of: 

receiving an event by the data base connector; 

determining* by the data base connector, in accordance with a 
data structure of the data base connector, that the data base has 
subscribed to the event; and 

sending, by the data base connector, the event to the data base. 

6. The method of claim 1, further comprising the step of: 

receiving an event, by the data base connector; 

determining, by the data base connector, in accordance with a 
data structure of the data base connector, that a neighbor hub is 
connected either directly or indirectly on the least-cost path to a 
subscriber for the event; and 

sending, by the data base connector, the event to its neighbor hub, 
so that the event can be forwarded to the subscriber. 

7. The method of claim 1, wherein the sending step includes the step of: 

sending an event, by the data base connector, to one of its 
neighbor hubs when a data structure in the data base connector indicates 
that the data base subscribes to events having the type of the event. 

8. The method of claim 1, wherein the sending step includes the step of: 

sending an event, by the data base connector, to one of its 

neighbor hubs when a content filter in a data structure of the data base 
connector indicates that the data base subscribes to events having values 
found in the event. 
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3. Detailed Description of Invention — 

Related Application 

U.S. Application Serial No. , filed concurratly herewith, 

entitled 'Middleware For Enterprise Information Distribution" of Bracho 

and JankowskL 

A ppendices 

Appendix A, which is a part of this specification and is herein 
incorporated by reference, contains a summary of exemplary system events 
that can be passed between hubs in a preferred embodiment of the present 
invention. 

Background of the Invention 

This application relates to an information publishing system and, 
more particularly, to a method and apparatus for connecting a legacy data 
base to an information publishing system. 

Certain conventional systems use a "transactional" model for 
exchanging information between nodes of data processing system. In a 
conventional transactional model, two applications initiate a synchronous 
"transaction" that is maintained for as long as information is being 
exchanged between the nodes. The transactional model requires that a 
transaction be defined for each business activity. When nodes on widely 
disparate portions of a network attempt to communicate via the 
transaction model, it is often difficult to define a transaction that works 
well on all parts of the system. Moreover, a transaction can only involve 
the nodes that began the transaction. Another node cannot join the 
transaction in the middle. This scheme is unsuited for a system in which 
nodes do not know about all other nodes in the system. 

Many commercial enterprises still use software that was developed 
long ago and is no longer supported by its manufacturer. Such software 
is called "legacy software." In addition, many commercial enterprises use 
commercial software products. It is not always possible or desirable to 
modify existing commercial software and legacy software to operate with 
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a new networked system. The commercial software and legacy software 
may be very complex, making it difficult and expensive to modify. A 
company may be wary of making modifications to a stable system that is 
working consistently. Moreover, there may not be any computer 
programmers at a company who understand the legacy system in enough 
detail that they can make modifications to it Lastly, a company may not 
have the source code for a legacy application if it purchased the 
application from a commercial vendor. A company also may not have a 
legal right to modify commercial data base software. What is needed is 
a way to integrate commercial and legacy data base software into a 
networked system without having to modify the data base software itself. 

Summary of the Invention 

The present invention overcomes the problems and disadvantages 
of the prior art by providing a "data base connector" element that can act 
as either a publisher or a subscriber in the network. 

The present invention is implemented as a type of "middleware." 
Middleware is software that is located between an application program 
and a control-level program. Middleware is "network centric" and does 
not concentrate on a specific user interface or on the organization of a 
specific database. The described embodiment includes a plurality of 
"publisher" entities, who publish information, and a plurality of "subscriber" 
entities, who request and use the information. Publishers and subscribers 
are connected to each other through a network. The network is a "store 
and forward" network whose routing is "content-based" In a content- 
based routing system, information is routed based on the content of the 
information, and not on the addresses of publishers or subscribers in the 
system. In the described embodiment, information is distributed to many 
subscribers in parallel 
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In the described embodiment, the basic quanta of information is 
called an "event" Publishers publish events and subscribers subscribe to 
events that match criteria defined by the subscriber. In the described 
embodiment, events are represented by data structures in the C 
programming language, although any appropriate representation can be 
used. 

Publication and subscription are performed asynchronously. 
Publishers and subscribers do not have direct knowledge of each other. 
The system receives published event from a publisher and routes the event 
to all appropriate subscribers. Each subscriber is guaranteed to receive all 
events published on the system if, and only if, they match the subscription 
criteria specified by the subscriber. 

The described embodiment includes an Application Programming 
Interface (API) for publishers and for subscribers* Hie API defines a 
plurality of procedures that allow respective publishers and subscribers to 
interface to the system. Thus, various types of publishers and subscribers 
can be connected to the system, as long as they use the interface 
procedures defined in accordance with the APL The described 
embodiment also includes support for a plurality of software elements such 
as common databases, installation &nd administration tools, and logging 
facilities. Thus, the described embodiment is termed an "enterprise 
system" because it can be used throughout the entirety of a commercial 
enterprise. 

The described embodiment of the present invention makes it easy 
to integrate legacy systems, legacy applications, and legacy hardware into 
the system and attempts to minimize the amount of information that a user 
must learn to use the system. Because communication within the system 
is based on asynchronous "events," the present invention can be 
implemented on a heterogeneous network that includes both PCs and 
mainframes executing under various operating systems and running various 
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types of applications. The described embodiment utilizes a 
distributed-object environment and a preferred embodiment of the present 
invention implements the Common Object Request Broker (CORBA) 
standard 

In accordance with the purpose of the invention, as embodied and 
broadly described herein, the invention relates to a method of connecting 
a data base to a publisher/subscriber network, so that the data base can 
publish events to the network, the method comprising the steps, performed 
by the data processing system, of: providing a link so that the data base 
can communicate with a data base connector computer program by way of 
a transaction monitor computer program; setting up the data base 
connector as a publisher hub in the network; receiving input, by the data 
base, from a user that alters data in the data base; informing the 
transaction monitor that the data has been altered; receiving input from 
the user indicating that the altered data should be committed; informing 
the transaction monitor that the altered data is committed; and sending, 
by the data base connector, in accordance with a message from the 
transaction monitor that the data is committed, a published event to the 
network in accordance with the altered data. 

Objects and advantages of the invention will be set forth in part 
in the description which follows and in part will be obvious from the 
description or may be learned by practice of the invention. The objects 
and advantages of the invention will be realized and attained by means of 
the elements and combinations particularly pointed out in the appended 
claims and equivalents. 

The accompanying drawings, which are incorporated in and con- 
stitute a part of this specification, illustrate several embodiments of the 
invention and, together with the description, serve to explain the principles 
of the invention. 
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Detailed Description of the Pref er red Embodiments 

Reference will now be made in detail to the preferred em- 
bodiments of the invention, examples of which are illustrated in the 
accompanying drawings. Wherever possible, the same reference numbers 
will be used throughout the drawings to refer to the same or like parts. 

L Overview 

Fig. 1 is a block diagram of a networked computer system 100 in 
accordance with a preferred embodiment of the present invention. 
Networked computer system 100 includes a plurality of publishers 102, 
110, and 116 and a plurality of subscribers 104, 112, and 118. Publisher 
102 and subscriber 104 are connected to a network 120 through a hub 
106. Publisher 110 and subscriber 112 are connected to network 120 
through a hub 108. Publisher 116 and subscriber 118 are connected to 
network 120 through a hub 114. Hub 106 and its connected publishers 
and subscribers are in a first territory 130. Hubs 108 and 114 and their 
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connected publishers and subscribers are in a second territory 140. Other 
territories (not shown) also exist in network 120. "Hubs," "publishers," 
"subscribers," and "territories" are discussed below in turn. 

As indicated by dotted lines in Fig. 1, each publisher, subscriber, 
and hub can be located in separate computers (102, 104, and 106), in the 
same computer (108. 110, and 112) or in some combination of separate 
computers and the same computer (114, 116, and 118)- Hubs can have 
zero or more publishers and zero or more subscribers. Hubs can also be 
directly connected to other hubs. 

It will be understood by persons of ordinary skill in the art that 
each computer (represented in Fig. 1 by dotted lines) includes a CPU, a 
memory, and input/output lines. These elements are not shown in the 
figure for the sake of clarity of example. Each computer can also include 
numerous other elements, such as disk drives, keyboards, display devices, 
network connections, additional memory, additional CPUs, etc The 
publishers, subscribers, and hubs preferably are implemented as software 
instructions stored in a memory and executed by a processor of a computer 
system. Usually, the publisher, subscriber, and hub software is executed 
by a processor of the computer in which the software is stored, although 
a processor of another computer system could also execute the software. 

A preferred embodiment of the invention runs under the Solaris 
operating system, Version 2.4, Solaris is a trademark of a registered 
trademark of Sun Microsystems, Inc. in the United States and other 
countries and is based on the Unix operating system. Unix is a registered 
trademark in the United States and other countries, exclusively licensed 
through X/OPEN, Ltd.. Networked computer system 100 uses a network 
communication protocol, such as TCP/IP, although any appropriate 
protocol can be used to implement the present invention 

In the described embodiment, a "publisher" publishes events of 
certain types on the network 120 and a "subscriber 19 subscribes to events 
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of certain types. The publisher and subscriber operate asynchronously 
and are unaware of each others existence. Use of a "publish and 
subscribe" model insulates applications from the network and from each 
other. Publishing can be thought of as broadcasting an event The event 
type is analogous to a radio station. Applications interested in a particular 
station subscribe (or tune in to) a specific event type. Just as in radio 
broadcasting, where all parties involved must agree in advance on a set of 
possible frequencies, applications in the described embodiment must agree 
in advance on a predetermined set of event types. 

The described embodiment of the present invention uses 
"subscription by content" Subscribers specify what they want based on 
an event type and on the content of the event The described embodiment 
makes use of "store and forward* techniques for events. This term means 
that the system buffers event, so that, even if a publisher is off-line, a 
subscriber can still retrieve events. Similarly, a publisher can publish 
events even if a subscriber is off-line. 

The described embodiment is managed in units of hubs. A hub, 
such as hub 106, is a local connection point for a publisher and/or a 
subscriber. Both publishers and subscribers are called "clients" of hubs. 
A publisher uses an "advertisement 1 " to tell the system what types of events 
it intends to publish and how it intends to publish them (e.g^ daily, as each 
event trigger occurs, etc). Advertisements are registered with the hub 
connected to the publisher during the installation of the publisher. An 
advertisement must have a unique name. In addition to containing a name 
of an event type to be published, an advertisement contains other 
information about the publisher. This information can include the priority 
level for the published events, for how long the events are valid, eta Hubs 
transmit advertisements to all potential subscribers. Hubs transmit 
published events to all subscribers who have subscribed to events of that 
type, whose content matches the subscriber's subscription. 
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IL Publishers and Subscribers 

The following paragraphs describe the steps required to create 
an application (either a publisher or a subscriber) and to install it on a 
hub. The following paragraphs further describe the steps performed by 
an example publisher to publish events and by an example subscriber to 
subscribe to events- The described embodiment allows a programmer to 
write software for applications (publishers and subscribers) in a high level 
language and to interface with the hub using routines defined in an API 
and using event manipulation routines generated for each user-defined 
event type. 

Fig. 2 is a flow chart showing steps performed to install an 
application, e.g., a publisher, on a hub. Fig. 3 is a flow chart showing 
steps performed by an installed publisher to publish an event Fig. 4 is a 
flow chart showing steps performed by a subscriber of Fig. 1 to subscribe 
to events of a certain type and content As discussed above, both 
publishers and subscribers preferably are implemented as software 
programs executed by a processor. 

The described embodiment is centered around the sending 
(publication) and receiving (subscribing) of events. Before a publisher 
can publish events, the publisher must define and advertise the events that 
it will publish. In order for the events to make sense, publishers and 
subscribers need to understand each other. For this reason, the described 
embodiment uses a standard specification language to define events. In 
step 202 of Fig. 2, the publisher defines one or more events that can be 
published by that publisher. The described embodiment of the described 
embodiment allows definition of events using an industry standard 
Interface Definition Language (IDL). IDL is a standard interface 
propagated by the Object Management Group (OMG), although any 
applicable syntax for describing the structure of the event could be used 
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in coajunction with the described embodiment In step 204, the OMG IDL 
definitions of the events are translated into data structures in the C 
programming language. 

Assume, for example, that an application publishes "SalesOrder" 
events. Before the application could be added to the system, and assuming 
that no other applications dealing with SalesOrder events already existed, 
a programmer would define a "SalesOrder" event using OMG IDL as 
follows: 

//filename: ordertddl 

interface SalesOrder { 
struct Address { 

string street; 
string city; 
string state; 
unsigned long zip; 

>; 

attribute string customer jname; 
attribute Address customer_address; 

}; 

The above syntax defines an event as an "interface" and defines 
the data members in the event as "attributes." 

After one or more events have been defined, the events are 
translated into structure definitions of the C programming language. 
Preferably, this translation is performed by an OMG IDL compiler, which 
generates a header file and a code file for each event. The generated 
header file contains simple C-language structures that represent the event 
declarations for the typed functions defined in the code file. The C 
structure definition generated for the above example event of type 
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SalesOrder is: 

typedef struct SalesOrderjVddress { 

nxsString street; 

nxsString city; 

nxsString state; 

nxsULong zip; 
} SalesOrder_Address; 

typedef struct SalesOrder { 

nxsString customer jiame; 

SalesOrder_addresF oistomer_address; 
> SalesOrder 

A person of ordinary skill in the art will easily understand how the DDL 
of the example translates into the C programming language structure 
definitions shown above. 

The code file generated from the event definition contains 
procedures for manipulating events of the defined type (here, for the 
SalesOrder event). The procedures perform at least the following 
operations: 

For use by a publisher; 

Create event of type SalesOrder, 
Publish event of type SalesOrder, 
Destroy event of type SalesOrder 

For me by a subscriber; 

Print contents of event of type SalesOrder, 
Register Subscription for event of type SalesOrder, 
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A person of ordinary skill in the art will understand that, although 
the above plurality of procedures is generated for each defined event, the 
operation of the procedures differ due to the differences in the structures 
of the event The procedures also differ due to the fact that the described 
embodiment uses typed function to prevent programming errors. 

The process of installing a process application in a hub includes 
storing one or more advertisements in the hub, as shown in step 206. 
These advertisements define types of events that the hub knows about 
An advertisement includes the name of the advertisement, a description 
of the event that a publisher publishes (e.g., a SalesOrder event), a 
description of how the publisher publishes its events (e.g., daily, when an 
event trigger occurs, etc.), the name of the event type, the priority level of 
the events, and the expiration time on the events (also called "time-to- 
live"). Although not shown in the Figure, the described embodiment also 
allows access control permissions for the various event types to be set 

The described embodiment also includes predefined routines in 
an API, which are available to the publisher and subscriber software and 
which include routines to perform at least the following functions: 

Register a client, 

Reestablish a client with an existing session, 
Unregister a client. 
Registering intent to publish, 
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. Unregistering a publication, 
Publishing an event, 
Subscribing to an event, 

Reactivating an active subscription to an event, and 
Cancelling a subscription, 

Other APIs in accordance with the present invention may include 
somewhat different API functions. In addition, the API preferably 
includes a •can_subscribe w routine and a "canjuiblislf routine that return 
a Boolean value indicating whether the calling application can subscribe 
to or publish events of a certain type. The API also includes a 
H get_currcnt_envelope" routine that returns information about the 
publisher of an event and how the event was published. (This routine can 
only be called from the call-back procedure). A call-back procedure is 
called, e.g., when a subscriber receives an event Fig. ? shows a format of 
an envelope data structure for an event, which is discussed below in 
connection with event routing. 

It will be understood that when the event description for a 
publisher or a subscriber is initially translated into, e.g., Q the event 
header file, whose generation is discussed above, is included within the 
application software source code. Thus, in the example, the publisher has 
access to the definition of the SalesOrder event The translation also links 
the event manipulation routines and API routines into the application at 
this time. The hub, along with other hubs, transmits a notice of the 
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advertisement existence to potential subscribers, as discussed below. 

Once a publisher is installed in a bub, it is free to publish 
advertisements and events. Fig. 3 is a flow chart showing steps performed 
by a publisher of Fig. 1 during operation of the publisher. Steps involving 
a call to the event manipulation routines that are created by compiling the 
BDL are indicated by an asterisk in the Figure. 

As shown in step 302 of Fig. 3, the publisher first registers itself 
as a client with the hub to which it is connected. The publisher next 
advises the hub of which "advertisement" it will use when publishing. An 
advertisement represents an "intent to publish" and tells the hub what type 
of event the publisher will be publishing. To advise the hub in step 302, 
the publisher tells the hub the nam* of an advertisement that has been 
previously installed in the hub (see Fig. 2). 

In step 304, the publisher waits until it is time to publish an event. 
Some publishers, such as in the example above, publish each event at the 
time that it occurs. Other publishers wait until a specified time, such as 
once a day, and publish all unpublished events at that time. For example, 
a first publisher may publish an event whenever a human operator enters 
a sales order into the system. A second publisher may publish the same 
type of event on an hourly basis. Once the publisher determines that an 
event is to be created, it calls (in step 306) one of the event manipulation 
routines that creates a C structure having the proper format for the event 
to be published. 
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In step 308, the publisher calls one of the event manipulation 
routines to publish unpublished events as discussed below in more detail. 
In step 310, the publisher calls one of the event manipulation routines to 
destroy the published event. (In general, in the described embodiment, 
whatever entity is responsible for allocating an event is also responsible 
for destroying that event) 

In step 312, the publisher determines if it should cease execution. 
If not, control returns to step 304. If so, in step 314, the publisher 
unregisters itself with the hub and ceases execution. Advertisements are 
kept in the hub to indicate that a publisher could execute and send those 
events. This information is needed to build routes to subscribers, as 
described below. Although not shown in the Figure, other publishers 
connected to the same hub may operate asynchronously with the steps of 
Fig. 3. 

Subscribers subscribe to events of particular event types. Fig. 4 
is a flow chart showing steps performed by a subscriber of Fig. 1 during 
operation of the subscriber. The subscriber first registers itself as a client 
of the hub. Then for each subscription, it registers a "call-back" 
procedure. 

As shown in step 402, the subscriber next registers itself as a 
client with the hub to which it is connected. The subscriber then registers 
a "subscription'' for the event type that it wishes to receive through the 
hub. (The subscriber can look at the bub to see what types of events are 
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advertised.) A subscription specifies a type of event, and can further 
specify a -filter" indicating that the subscriber wishes to receive only events 
of a certain type that also have certain values in certain fields. 

In step 404, for each subscription, the publisher defines a 
predetermined "call-back - procedure. The call-back procedure will be 
initiated by the hub whenever the hub determines that the subscriber has 
received an event of a certain type. The format of the callback may be 
different for each operating system on which the present invention is 
implemented and the call-back procedure can be practically any procedure 
that is performed when an event is received. For example, in step 406 of 
Fig. 4, the call-back procedure could print the contents of the event (using 
one of the event manipulation procedures designed to print an event of 
that type). Because a call-back procedure is defined for each subscription, 
a call-back procedure must be defined for each type of event to which the 
subscriber plans to subscribe. In the described embodiment, an event 
passed into a call-back procedure is destroyed when the call-back 
procedure returns. Thus, if the subscriber wants to keep any information 
of the event, the information should be copied out of the event within the 
call-back procedure. 

The subscriber loops until it is time to cease execution (see step 
408). The call-back procedure may be activated zero, one, or many times 
during this loop, as events of the specified type and values are received by 
the hub. If an event subscribed to by the subscriber is received, the 
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call-back procedures is executed in step 406. If, in step 408, the 
subscriber determines that it is time for it to quit, the subscriber optionally 
unregisters its subscription, unregisters itself with the hub, and ceases 
execution. Subscriptions can also be retained in the hub, to receive future 
events while disconnected. The hub will queue events arriving for the 
subscriptions. Although not shown in the Figure, other subscribers 
connected to the same hub may perform steps asynchronously with the 
steps of Fig. 4. 

The following examples are written in the C progr ammin g 
language and show example software for a publisher and subscriber. 

/• 

* publishx 
7 

#include <nexus.h> 

#include *nxs_output/order_nxs.h' t 

int main() 
{ 

SalesQrder * event; 
nxsCIientID id; 
nxsPublicationID pubjd; 



/* Register the Client and the publication */ 
nxsCreateCIient ("order publisher", NULUNULL, 0, &id); 
nxsRegisterPublication (id, "order.advertisement", &pubjd); 



/• Create the event •/ 

event = nxsCreate_SalesOrder(); 

event- > customer_name = "Jim Nexus*; 

event- >customer_address.street « "12345 Anistreet"; 

event- >aistomer_addre$s.dty = "Mountain View"; 

event- >customer_address.state = n CA w ; 
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event- >customer_address.zip * "95000"; 



/• Publish Event V 

nxsPublish.SalesOrder (id f pub.id,eventAO); 



/• Clean up */ 
nxsDestroy_SalesOrder(event); 



/• Unregister the publication and client */ 
nxsUnxegisterPublication (idjmb.id); 
nxsDestroyClient (id); 

return (0); 

} 

/• 

• subscriber 

v 

#include <nexusJi> 

#indude *nxs^output/order.nxsA* 

/• Callback function to be called when each event is received */ 
void event.callback ( 

nxsCIientID id, 

nxsSubscriptionID subjd, 

nsxULong seq^nunLhigh, 

nsxULong seqjiumjow, 

SalesOrdcr *the event, 

void *client,data) 



char *st; 

printfCEvent receivedlX^); 

st = nxsStringify_SalesOrder(the_event); 

printf(st); 

free(st); 

} 

int main(int argc, char ••argv) 
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{ 

Sales Order 'event; 

nxsClient ID id; 

nxsSubscriptionID subjd; 

/• Register Client and subscription */ 

/* (Only subscribe to specific ZIP codes) */ 

nxsCreateOient ("order subsmW,NUIX>OJLU 0,&id); 

nxsRegisterSubscription SalesOrder(id, 

"customer.address-zip = * 95000", 

eventjaUbackJJULL,&subJd); 

/* Main loop •/ 
nxsMainLoop(id); 

/* Unregister subscription and client •/ 
nxsUnregister Subscription(id t subJd); 
nxsDestroyOient(id); 

return(O); 



III. Hubs 

Fig. 5 is a block diagram showing details of hub 106 of Fig. 1. 
Hubs 108 and 114 of Fig. 1, and indeed all other hubs in the described 
embodiment, have a similar structure. Hub 106 is connected to remote 
hubs 108 and 114 via network 120 (or directly) and to zero or more 
publishers 102 and zero or more subscribers 104. Hub 106 also receives 
information S30 relating to hub administration, information 532 relating 
to management of its clients (publishers and subscribers), and information 
536 relating to system event management* 

All input and output to and from hub 106 is queued. For 
example, events received by hub 106 from remote hub 108 and from 
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publisher 102 arc stored in event priority order in respective event queues 
502, 504 until hub 106 has time to process them. As a further example, 
events to be sent by hub 106 to remote hub 114 and to subscriber 104 are 
stored in event priority order in respective event queues 506, 508 in 
memory until hub 106 has time to send them. Hubs distribute events 
using a first-in, first-out policy. This means that all events having a same 
priority level will be delivered by hub 106 in the order that they are 
accepted from the publisher. All events with a higher priority level are 
delivered earlier than waiting events with a lower priority level The 
described embodiment guarantees to keep the ordering of like-events from 
a single publisher as the events move though the system. This is 
important, for example, in transaction processing where an order of 
updates must be maintained Inter-publisher ordering is not guaranteed, 
since it depends on routing and availability issues. 

Fig. 5 also shows the following functional blocks inside hub 106: 
client management block 510, event management block 512, preprocessor 
block 514, store block 516, match block 518, and remote administration 
block 520. Client management block 510 deals with registering and 
unregistering clients. Event management block 512 deals with managing 
system events, such as receipt of new connections, types, routings, 
advertisements, and subscriptions. Pre-process block 514 performs tasks 
such as adding envelope information to an event Store block 516 is a 
memory of the hub. Match block 518 adds routing information to events, 
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filters events in a manner described below in connection with event 
routing, and routes events to appropriate other connected hubs. Remote 
administration block 520 performs system administration tasks. 

Fig. % is a diagram of data structures stored in a memory 690 of 
hub 106 of Fig. 1 that is accessible by all the functional blocks of Fig. 5. 
The data structures include a table of installed advertisements 700, a table 
of registered clients 730, a table of registered publications 760, and a table 
of registered subscriptions 770. Data is placed in the data structures of 
Fig. 8 as the publisher and subscriber perform the various steps of Figs. 2, 
3, and 4 as follows. 

Step 202 of Fig. 2 fills entries of installed advertisements table 

700. 

Steps 302 and 402 of Figs. 3 and 4 fill entries of registered clients 
table 730. The user name field 734 and user password field 736 may have 
a NULL value to indicate that the current user ID should be used. Hub 
name 737 and territory name 740 can be set to NULL to indicate use of 
a default hub and territory. Flags 742 include, for example, a Boolean 
value "can-back-on-any-thrcad," which indicates that event call-backs come 
on new threads. 

Step 302 of Fig. 3 also fills entries of registered publications table 

760. 

Advertisement name 764 is the name of an advertisement that 
has been installed in the hub. Step 404 of Fig. 4 also fills entries of 
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registered subscriptions table 770. Content filters 774 are discussed below. 
A name of a callback procedure is kept locally in the subscriber (by the 
C API). The API finds the callback from the subscription ID. A client 
data field, which is also kept by the API, allows information associated 
with the subscription to be passed back with each event callback. The 
information that is passed back has meaning to the subscribing 
application. 

The following paragraphs describe the various types of content 
filters that can be specified by a subscriber when it registers a 
subscription. As shown in the above example, subscribers can request 
that the hub filter the incoming flow of events and only pass events to the 
subscribers that match certain criteria. A filter preferably is specified as 
a expression string sent by the subscriber as a parameter to the routine for 
registering subscriptions. The expression string syntax for a content filter 
in the described embodiment is as follows. (Of course, any appropriate 
Syntax could be used): 
iymhQl nif^Tfog types allowed for 



equal to 



all basic types 



not equal to 



all basic types 



> 



greater than 



numeric and string types 



greater than or equal 



numeric and string types 



or 



and 



logical AND 



logical OR 



expressions or Booleans 
expressions or Booleans 
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not logical NOT expressions or Booleans 

Event attribute names are used to denote which field in the event 
should be compared. Sub-fields (those inside structures) are specified 
using dot notation- Names can also be enumerated types, as is known to 
persons familiar with the C programming language. Once a content filter 
has been specified, it is used during event routing as described below in 
connection with Figs. ?-13. Information describing each content filter for 
a subscription is stored in field 774 of Fig. 3. 

Fig. 6 is a diagram showing data structures stored in a 
memory 690 of hub 106 of Fig. 5. All hubs contain similar data structures. 
The described implementation uses a distributed objects model but any 
appropriate organizational structure could be used. Details of the data 
structures of Fig. 6 axe listed in Fig. 7 . Ideally, the data structures 
of Fig. 6 describe all advertisements in the system and indicates a 
neighbor hub to which the current hub should send events of certain types. 
Figs. 11 and 13, respectively, describe the steps to populate the data 
structures of Fig. 6 and to use to the data structures of Fig. 7 to 
route events among the hubs. Fig. VL shows an example of the data 
structures populated with data. 

Hub 106 (the "current hub") includes data objects representing: 
each client of the current hub that is a subscriber (indicated by "Client" 
684 and "S" 695) and each neighboring hub connected to the current hub 
("Neighbor A" 696 and "Neighbor B w 697). The current hub keeps track 
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of the subscription objects of its neighbor hubs. Subscription objects *S" 
650 represent ail subscribers that can be reached through the respective 
neighbors. Each neighbor object has two associated cost values: "mycost" 
and "then-cost*. "Mycost" represents a cost of sending information from 
the current hub to the neighbor. • , Thei^cost ,, represents a cost of sending 
information from the neighbor to the current hub. Theircosf used to 
define a route, as described below. The subscribing hub will ask the 
"publishing" hub with the lowest "theircost 1 ' to forward the events. 
"Mycosf preferably is only used to inform the neighbors of how much it 
would cost to the current hub to send information through that link. A 
"cost" may be figured in a number of ways. For example, a cost may 
represent a financial cost, a cost in units of time, a cost as a measure of 
convenience, or any other appropriate cost 

Hub 106 contains a ("RemoteAd") object for each advertisement 
that has been registered in the system (Le., for each intent to publish, step 
202 of Fig. 2). Each RemoteAd object points to one or more "AdSource" 
objects, each of which represents a path between the current hub and the 
hub on which the publisher of the ad resides. Each AdSource object 
stores a cost associated with its path to the original publisher of the ad. 
Thus, the "cost" value for each AdSource contains the total cost for 
sending an event from its source to the neighbor of the current hub or, 
alternately, to the current hub. 

Each AdSource object has an associated list of "sink objects." 
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(SinkCa and sinkNb preferably are located in a single list, although not 
shown that way in the Figure.) Each sink object has an associated list of 
subscriptions. For example, SinkCa has a list 505 of all subscriptions of 
Client 694 that matched to the advertisement of Remote Ad 510. 
Similarly, SinkNb has a list 515 of all subscriptions of Neighbor B (and 
of all subscriptions that can be reached through Neighbor B) that have 
matched the advertisement of Remote Ad 510. 

Each neighbor object also has an associated AdSourceRef list that 
points to AdSources for all paths between a publisher and the neighbor. 
The paths are used for routing system events between hubs, as described 
below. 

IV. Event Routing Between Hobs 

Fig. 11 is a flow chart showing details of steps performed by hubs 
106 t 108, and 114 of Fig. 1 to populate the data structures of Fig. 6 
These steps are performed, for example, when the network is first 
initialized. Subsequently, various hubs may issue "system events" to tell 
other hubs that changes have occurred in hub connections, event types, 
advertisements, routings, subscriptions, etc. Appendix A, which is a part 
of this specification and is herein incorporated by reference, contains a 
summary of exemplary system events that can be passed between hubs in 
the described embodiment 

In Fig. 11, the name of the system event of Appendix A that 
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affects a step in the flow chart is shown next to the step. In step 1002, 
hubs send system events to each other to define the physical connections 
between hubs in the network. Each hub creates neighbor objects 
representing physical connections to its neighbor hubs (see Fig. 6 ). In 
step 1004, the hubs send system events to each other to define the types 
of events for which advertisements can be published. Each hub makes 
sure it knows all the events. This step is performed when adding a hub to 
a territory. In step 1006, hubs that are connected to a publisher send 
system events to other hubs, which are forwarded among the hubs, to 
distribute advertisements among the hub. For example, the system event 
NXS_SYS_EVENT_CREATE_^W_ADVERTISEMENT of Appendix 
A causes the creation of RemoteAd objects in the hubs (see Fig. 6 ). 

In step 1008, hubs that are connected to a publisher send system 
events to other hubs. The system events are forwarded among the hubs 
to determine routes from the publisher's hub to other hubs. (The system 
event NXS SYS_EVENT NEW^ROUTES causes the creation of 
AdSource objects in the hubs (see Fig. 6 ). To register the existence of 
a route, an initial hub sends a system event to its neighbors, containing an 
advertisement name/ID, its (the publishing hub's) name and territory, and 
a cost associated with sending an event from the publishing hub to the 
current hub. In the described implementation, the cost is initially set to 
zero. Each neighbor hub repeats this process, adding the cost of the 
connection over which that hub received the event In each hub, if this is 
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the fast route to the hub, then the local clients are checked for 
subscription matches (This action may result in a NEW_SUBSCRIPTION 
system event to the sender of NEW^ROUTES). Each route is considered 
separately for forwarding. The route is not forwarded to the hub from 
which it was received, to the originating hub, or to a hub that has already 
seen the event, (determined from the routing list, as discussed below). 
The route is only forwarded to other hubs if it is the first route for the 
RemoteAd or if it is the second route and the destination bub is the 
current route provider. 

In step 1010, hubs connected to a subscriber send system events 
to other hubs to register a subscription against an advertisement known 
about by the other hubs. (The system event 
NXS_SYS_EVENT_NEW_SUBSCRIPTIONS sends subscriptions to other 
hubs, see Fig. 6 ). A hub receiving the system event creates a 
subscription object (see Fig. 6 ) and tells the RemoteAd about it. An 
AdSource having a least-cost path is called the current AdSource. The 
RemoteAd tells the current AdSource, which creates a sink and a 
subscription object of the Neighbor object (if a sink and a subscription 
object do not exist). The sink then adds a SubscriptionRef entry (e.g., 
505, 512) for the subscription object If the advertisement was received 
from another hub, the current hub forwards a system event for the new 
subscription to the neighbor that is a part of the current least-cost route. 
This forwarding of subscriptions to other hubs is an important 
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aspect of the present invention. It essentially creates a chain of 
subscriptions from a hub of a subscriber back to the hub of the publisher. 
This chain follows the least-cost route between the publisher and the 
subscriber. 

Fig. 12 shows an example of the creation of a chain of 
subscriptions from a hub of a subscriber to a hub of a publisher. Fig. 12 
shows five hubs A, B # Q D, and E. Hub A has a connected publisher P. 
Hub C has a connected subscriber S. In the example, each connection has 
a cost of "1". Thus, for example, there is a route of total cost = 2 
between hub A and C and a route of total cost = 3 between hub A and 
C. 

Fig. 11 shows the status of the hubs after step 1010 of Fig. 11. 
Connections, event types, and routes have been distributed among the 
hubs and the RemoteAd, AdSource, Neighbor, and AdSourceRef objects 
have been created in each hub. 

In the example, subscriber S registers a subscription on hub C. 
(Hub C had previously created a subscription object 1102 when S 
registered itself as a client, indicating that the subscriber S is a client of 
hub C). Hub C then routes a "new subscription system event" (a 
"subscription") to a neighbor hub that is on a least-cost path to the 
publisher of the advertisement for the event In the example, hub C will 
route the subscription to hub B, since the cost from hub B to the 
publisher hub A is T. When hub B receives the subscription, it adds a 
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subscription object 1104 connected to a neighbor object for hub Q 
indicating that the subscriber can be reached through hub C 

Hub B then routes a subscription to a neighbor hub that is on a 
least-cost path to the publisher of the advertisement for the event. In the 
example, hub B will route the subscription to hub A, since the cost from 
hub A to itself is "0". When hub A receives the subscription, it creates a 
subscription object 1106 connected to a neighbor object for hub B, 
indicating that the subscriber can be reached through hub B. Hub A does 
not route the subscription further, since it is the originating hub for the 
advertisement that is being subscribed to. 

Once the data structures of Fig. 12 have been established, an 
event published by publisher P will be sent hub-to-hub along the path 
defined by the subscription objects 1106, 1104, and 1102 until it reaches 
subscriber S. 

Fig. 13 is a flow chart showing details of steps performed by the 
hubs of Fig. 1 to send published events to subscribers by routing the 
events through the hubs of the system. The steps of Fig. 13 are 
performed by 1) a hub that receives an event from its connected publisher 
(step 1202) or 2) a hub that receives an event from a neighboring hub 
(step .1203). The steps of Fig. 13 are performed by various hubs as each 
event is routed through the system. In the following paragraphs, the hub 
performing the steps of Fig. 13 is termed the "current hub." 

If the current hub receives an event from one of its connected 
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publishers (step 1202), the preprocessor 514 of the current hub initially 
adds an "envelope" to the event (step 1204). A format of an event 
envelope is described below in connection with Fig.*. Preprocessor 514 
then determines in step 1204 whether the event type of the event is 
registered in the hub. If not, the publisher cannot publish the event If 
so, in step 1206, the hub places the event in the hub's incoming event 
queue for further processing. In the described embodiment, the event 
queue discards duplicate events (as determined by a sequence number or 
time stamp of the event envelope). 

If the current hub receives the event from a neighboring hub (step 
1203), the neighboring hub places the event in the incoming event queue 
of the current hub. 

In step 1208, filter 518 of the current bub gets the event from the 
current hub's incoming event queue. Filter 518 then increments the time- 
spent field of the envelope, which indicates an amount of time spent in 
queue. In step 1210, filter 518 adds a routing block to the event. Each 
hub that routes the event adds another routing block to the event A 
format of two routing blocks is shown in Fig./0. 

In step 1212, the current hub locates a "current" AdSource object 
that represents all the subscribers which are interested in the event 
coming from that particular AdSource. This will usually represent a least 
a cost path between the current hub and the subscribers, (note that the 
described embodiment does not reroute once an AdSource data structure 
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is established. The AdSource object is located by either searching all 
RemoteAds for the current hub (if the event came from a publisher 
attached to the current hub) or from searching the AdSourceRef list for 
the neighboring hub (if the event came from a neighboring hub). Steps 
1216-1222 send the event to one or more subscribers. Steps 1216-1222 are 
performed for each sink object attached to the AdSource. Thus, steps 
1216-1222 are performed for each subscriber that has asked to receive 
events of the type being routed. 

It in step 1216, the time-to-live for the event is less than the 
time-spent field of the envelope, then the event has expired and is not 
routed further by the current hub (step 1218). Otherwise, in step 1220, 
filter 518 determines whether the event has contents that fall within 
parameters specified by the subscriber. The subscriber specified the 
content filter at the time it subscribed to the event type (see field 774 of 
Fig. %). For example, a subscriber may have requested to receive only 
those SalesEvents having where the customer lives in Los Angeles. If the 
event has values in the range specified by the subscriber, then the event 
is sent to the subscriber in step 1222 (either directly or by way of its hub, 
as described below). Each subscriber may have specified a different 
content filter (or no content filter). For example, a first subscriber may 
have specified that it wishes to receive SalesEvents where the customer 
lives in Los Angeles and a second subscriber may have specified that it 
wishes to receive SalesEvents where the customer lives in San Francisco. 



(66) #HPP10-27121 

In this example, it is possible that the event will match the first subscriber 
but not the second subscriber. 

In step Y W X filter 518 sends the event to the matching subscriber. 
The subscriber may be a client of the current hub, in which case the event 
is sent directly to the subscriber. Alternately, the subscriber may be 
connected to a neighboring hub, either directly or indirectly. If a 
matching subscriber is connected to a neighboring hub, the current bub 
will route the event to the neighboring hub (unless the neighboring hub is 
the hub o riginating the event, as determined from field 802 of the 
envelope, see Fig. ? J. The current hub also will not route the event to a 
hub that has already seen the event (as determined from the routing 
blocks attached to the event, see FigJO). 

In the described embodiment, the current hub only routes the 
event to a neighboring hub a single time, even if the neighboring hub has 
more than one matching subscription. Thus, if subscription object 651 of 
Fig. 6 matches the event, the event is forwarded to neighboring hub B. 
If subscription object 652 also matches the event, it is not necessary to 
forward the event to the neighboring hub B a second time. When 
neighboring hub B receives the event, it also will perform the steps of Fig. 
13 to determine whether any of its client subscribers match the event 

Fig. ? shows a format of an envelope data structure of an event. 
Hie preprocessor of Fig. 5 adds an envelope to an event received from 
its subscriber before the event is published. An envelope is associated 



(67) #^10-27121 

with each event and includes an origin hub 802, an adname 804, a 
publisher name 806, a territory name 808 f an initial time stamp 810, a 
time to live 812, a priority 814, flags 816, and a time spent field 822. 
Flags 816 are unused in the described embodiment In an alternate 
embodiment, the flags may indicate, e.g^ whether an event is "persistent" 
or "transient" 

Fig.10 shows an example format of two routing blocks of an event 
Each hub adds a routing block to an event that it routes through itself. 
The API also includes a get_cun*nt_route_info routine that returns 
information about the actual route that an event took to reach a certain 
subscriber. Routing information is stored by the system as linked list, one 
entry for each hub visited. Each entry includes: an outgoing time stamp 
for the current hub, a hub name of the current hub, and a territory name 
of the current hub. The routing information optionally includes a sixty- 
four bit sequence number initially assigned to the event by the publisher. 

V. Territories 

Each territory 130 and 140 of Fig. 1 is a collection of hubs with 
a common event dictionary. Territories reflect organization, and are not 
necessarily tied to geography or direct physical connectivity. In the 
described embodiment, all hubs within a territory must be fully connected, 
because advertisement information is not forwarded across territories. 
Thus, there is always some path, although it may be indirect, between two 
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hubs within a territory without having to leave the territory. In a 
preferred embodiment, hierarchies of territories exist in which lower level 
territories inherit the event dictionaries of their parent territory. For 
example, a corporation may choose to have a territory for each subsidiary, 
with all of them understanding certain "corporate events." 

A hub preferably may belong to only one territory. When a client 
(a publisher or a subscriber) connects to a hub, it specifies to which 
territory or territories it belongs. A client must belong to a territory 
because the meaning of an event, for example a SalesOrder, may be 
different In different territories. In the described embodiment, each hub 
has a predetermined default territory that is used if the application 
developer does not specify a territory. 

In an alternate embodiment, multi-territorial hubs are especially 
useful for inter-company communication. Two companies that decide to 
communicate using the described embodiment of the present invention 
may set up a joint territory, agreeing upon some event types and a format 
to be shared The hubs connecting the two companies will only forward 
events of this joint territory, since the territory information is kept as part 
of the advertisement, as described below in connection with event routing. 

VI. Database Connectivity 

Fig. It is a block diagram of a data base application 1302 
incorporated into the network 120 of Fig. 1. Database application 1302, 
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which includes a database library having interface routines 1304, allows 
users to access information in data base 1308. Data base 1308 can be a 
data base manufactured by, for example, Oracle, Sybase, or Informix. 
The invention can be implemented using any appropriate data base that 
is capable of operating in conjunction with a transaction monitor. 

Fig. If also includes a transaction monitor 1306. Transaction 
monitor 1306 preferably is the Encina transaction monitor, manufactured 
by Transarc Corporation. It can also be, for example, the Tuxedo 
transaction monitor manufactured by Novell. Alternately, any appropriate 
transaction monitor can be used to implement the present invention. A 
data base connecter 1310 having a data base library 1304 connects to 
network 120 to transmit and receive data from network 120. Data base 
connecter 1310 may include software performing hub functions or may 
connect to a separate hub. In Fig. l¥i data base application 1302 sends 
information to data base 1308. Data base application 1302 also requests 
information from data base 1308 and displays that information in human 
readable form. 

Data base connector 1310 can be a publisher, a subscriber, or 
both. If data base connector 1310 is a publisher, for example, it may 
publish an event each time a value is changed in data base 1302. It could 
also, for example, publish events at regular time intervals, reflecting the 
data that has been updated in the data base since the last publication. If 
data base 1302 is a subscriber, it stores the information of events it 
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receives in data base 1302. The described embodiment includes a 
configuration file (not shown) for data base connecter 1310- The 
configuration file specifies, for example, whether the database connection 
will be a publisher, a subscriber, or both. The configuration file also 
includes, for example, a description of events to publish and/or subscribe 
to. The configuration file also specifies information concerning the layout 
of data base 1308. 

Fig. 15 is a flow chart 1400 showing steps performed when the 
data base is a subscriber. For example, as events are received from 
network 120, data from the events arc added to data base 1302. Flow 
chan 1400 assumes that data base connector 1310 has already registered 
itself and its subscription^), as described above. When an event is 
received by data base connector 1310 in step 1402, the data base 
connector maps and stores the data in the event into data base 1306. The 
data is not "committed" to the data base until the data has been 
completely stored in the data base. "Commitment" means that the data 
is actually entered in the data base. Until the changes to the data is 
committed, they are kept in a temporary storage location. Thus, 
uncommitted data base can be "rolled back" and the data transaction 
cancelled at any time up until the "commit" operation is performed. 
During a "roll back" the changes in the data in the temporary storage are 
discarded and the data base is retained in its state before the changes 
were made. Under certain circumstances data base connector 1310 will 
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not issue a "commit" command until a certain event is received. 

Fig. 16 is a flow chart 1500 showing steps performed when the 
data base is a publisher. For example, as a human user adds, deletes 
and modifies data in the data base 1302, data connector 1310 sends 
periodic events to network 120, In step 1502, the transaction monitor 
1306 is informed that data base connector 1310 is a -node/ The exact 
manner in which this step is performed will vary, depending on the 
manufacturer of the transaction monitor 1306, but the step generally is 
well-known to persons of ordinary skill in that art In step 1504, the data 
base connector 1310 registers itself and its advertisements), as described 
above. 

Steps 1506-1512 show steps performed, e.g., as the user makes 
changes to data base 1308. When a data base transaction begins in step 
1506, data base 1308 informs transaction monitor that a transaction has 
begun, using, e.g., X/Open's XA protocol. Transaction monitor 1306 
informs data base connector 1310 that a transaction is occurring, and data 
base connector 1310 notes the transaction. In step 1508, changes are 
made to the data base by the user, but the user has not committed the 
changes). 

If, in step 1507, the user (or software making changes) indicates 
that the transaction should commit, this fact is communicated to 
transaction monitor 1306 in step 1510. Transaction monitor 1306 informs 
data base connector 1310, which pulls the committed data from data base 
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1308 and publishes an event including the committed data. Events are 
published as shown in Fig. 13. 14 to step 1512 the user (or software 
making changes) indicates that the transaction should roll back, this fact 
is communicated to transaction monitor 1306. Transaction monitor 1306 
informs data base connector 1310, which #1 forgets H about the changes of 
step 1506 and does not publish an event Thus, the described 
embodiment takes into account the commitment and roll back operations 
common to commercial data base operation. 

In an alternate embodiment, where the data base product 1302 
used does not include a transaction monitor, data base connector 1310 
can act as a transaction monitor when connecting with data base 1308. 
Data base connector 1310 still acts as a publisher and/or subscriber in 
this configuration. Data base 1308 thinks that it is connected to a 
transaction monitor, when it is really connected to data base connector 
1310. 

VII. Summary 

In summary, a preferred embodiment of the present invention 
includes a plurality of "publisher" entities, who publish information, and 
a plurality of "subscriber" entities, who request and use the information. 
Publishers and subscribers are connected to each other through a network. 
The network is a "store and forward" network whose routing is "content- 
based" 
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In the described embodiment of the present invention, the basic 
quanta of information is called an "event." Publishers publish events and 
subscribers subscribe to events that match criteria defined by the 
subscriber. Publication and subscription are performed asynchronously. 
Publishers and subscribers do not have direct knowledge of each other. 
The system receives published event from a publisher and routes the event 
to all appropriate subscribers. Each subscriber is guaranteed to receive all 
events published on the system it and only if* they match the subscription 
criteria specified by the subscriber. 

The described embodiment of the present invention makes it easy 
to integrate legacy systems, legacy applications, and legacy hardware into 
the system and attempts to minimize the amount of information that a 
user must learn to use the system. A legacy data base can be added to 
the network by way of a data base connector, which can be a publisher, a 
subscriber, or both* 

Other embodiments will be apparent to those skilled in the art from 
consideration of the specification and practice of the invention disclosed 
herein. It is intended that the specification and examples be considered 
as exemplary only, with a true scope of the invention being indicated by 
the following claims. 
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6.0 The System Events 



Twenty-three system events sr* used id cnmrmfflinr between hnbt. Tbey Ajbc seme 
cf ihe w-rW stractte of oaansl events, but ere ocbeewtse loully <fifiaent sod 

tcodeptth. 



The syucm event i" 1 * is '^fl* 1 —* in adDde/aujtyspackPhh: 



typedef struct n*sSyste«nveet«ei rfer { 

xutsOLoog leogtlw length °* • v * nt 

^^«nr>hryj asglejnwbex; tfsed to detect bogus events 

nxsULoag nexuj 9 *** 1011 ' Nexus version msstoec 

nn tff i yyg roottagjeffset; nxseventwratingBatry 

njcsOLoog sysjsveatjtypei NXS^SYSJOTWr^/ 

nxsOLong dstloffset; String dsta 

i nxaSyst u pi C iis ntii s srisr ; 



The vslnes fer sysjrraitJtype eta be found in trsnspoctfmbtosevest^h. All system 
event p n ^ ^i 'T t code ts declared in nrnmfrfr 1111 <ss mrthnrit of Nnrmffnh) tnd 



Vx system event dsts b e song compel of spsced sepstsied tokens. The possible 



Hrix*/ sst^ofsnychirscieise3s^ A .C037)s^^ 
lon( s signed 32-bit vstae 

^ Vyig sntastgned 32-bst vstae 
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Object references se tnntfwed in stringififd fans. 

System evena se used for several styles of conrnnmHtinn Dving cameokn 
^^IHb"^' system evens ire used ss peer-tot»er messages. "Inese exam «e no* 
seen, by oner tab*. Mo* oner eraus affect the sute of ne teoboty and may be 
f<ywaidedtbwfl>)uttbes«itc^ 



NXS_SYS_EVEMTjCONNECT_HUB 

Sending bub tune 
Sending bub territory 

y+M lr? bob in«mlng E*eatQueue::PuahCans\ner 
Motiving bub's cost 
Sending bub's cost 

this event is scot ss a ccsok of a call to NaaoaMnLmrHnhArim The 
sending bAlwssbeadycxei^ 

driving hub daea likewise when it wmxto±*ry&*^tk***te*a^ 
hob alieady has die inning EvcaCoe«rft nl^C a mmTrr of the receiving vis sa 
argmeot to Heaas ^rfmm-HnhMniin f iwnfriTIn b. K this is the fin* comecrioa far 
tencriviaghiAGlbjom 

(evaa types, ea&). System events are osed to leqaest tills fnmthcfcorJmg 
hnb; WSJSYSJVENTJTOJES^^ and 

NXS 3 YSJVENT JtH^JEST J^VEKnSEMQfFS* If the hub is already a 
t^ntw of the territory, it scads V|s con*> *to *e sender with 
NXS ,SYS JEVENT1NEW JLOOTES. The lecemng &*> atwmys requests names from 
the sender with NXS.^^pVENT JtEQUEST JbDUIES, H the connection cannot 
be acsfed. far ewpfe the territory name is wrong, the receiver scads a 



/string/ 
/stein?/ 

stria? 

along 

along 



/string/ Sending bob naae 
/string/ Sending bob territory 
/string/ Baesaa for connection failure 

Sfftf Trhcn ir^iin?^?^ f^fJUhm**** f«iwt Oesn op data structures. 

/string/ Sending bub nam (or neighbor name) 
/string/ Sending bob territory 

Tins system evem en be so* ^ 

IfaaBAAaiB^^ 

of the neighbor bob. Tie hah 

of the sentfing hub) and does a connection shutdown. This may cease the idUowing 
system events to be seat; NXS.SYS^VENTJFAIL.SUBSC3aFIF0N& 
MXSLSYS JVENTJMJEIEJO UIES, »* 
NXS^SYS^YENT J3El£TEJtf>VEKnSEMENTS. Qae the connection dean-op 
events ate sent, a NXS^SYS^VENT^pND.OT^TREAM ts delivered. 
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The sqnenoe of even* ft *e sae on tbc oeighbor hub receiving 
NXS.SYSJEVEKTJ)ISOONNECr.HUB. 

NXSJSYSJEVENTJEND.OP^STIIEAII 



/string/ Sending hub 
/string/ Sending hub territory 



bdkues the last event to be mta oa a 
HXSJBYS.EVEKT_REOUEST_EVBmYPES 



/string/ Sending hub 
/string/ Sending hub territory 



Send event typeswo* sender wi* 



Long . Huetoer of files F 

long Muttber of types r 

Kepeeeed f elees: 
/string/ .nexus file contents 
/string/ «ifr file contents 

xepeeted r tines ; 
string event type 



Loedd»IFR end Nexas files into 

is fixwnrded to sU connected neighbors enscpi the sender sod neighbors who hsve 
staesdy seen the event. 



MXSjSYS^EVB*T_FORWARO^EVBinYP^l£ 

uleng Address of Kventtypetile stnte 

long Nueber of event types T 

Repeeted T tims: 
string Event type not 



Said the event type fife sod event types to ill connected neighbors. Only sent to self 
when e re nr t y pes sre crested or nprts t wd 

NXSJSYS.EVENT 

/string/ Sending hub one 
/string/ Sending hub territory 



Deliver *H advertiseme nts to the seating hub with 
NXS JSYSJEVENI JIEW^ADVQniSEMENTS, 



HXSjSYS_EVEMT_KEW_ADVEITnSayCfnS 
long Munber of advertisements A 
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/stria?/ 


Adrertlaenent nasa 


/string/ 


Event type nana 


long 


Priority 


string 


Storage aode; *p* or *t* 




slant 


ulong 


Tin to live (seconds) 


/string/ 


Originating hub tune 


/string/ 


Originating hub territory 



for persistent or tran- 



O a— BnooceAds^far ibe listed advcniseacfltt. The originating bib b where the 
advertiscsneat vn created. The system event k forwarded to all comecssd neighbors 
excepted the aender and neighbor who have siresdy seen the event. 



NXSjSYS_EVQfTjCX)NNECTION_READY 

/string/ Sending hub na» 
/string/ sending hub territory 

The sending hub is ready to use the If die receiver is also ready, it replies 

with e NXS JSYS^VENT.OONNECnOM JtEADY. V the connection is already 
fitsHit^^ (he system event ts ignored. 

string Advertlaenaot nam 

Send die named advertisement fto all ennnrrrd neighbors. Only sent to self when 
advertisements ate creased. 



NXSJSYS_EVBiT_C^ 

/string/ Advertisement naae 

/string/ Originating hub oaste 

/string/ Originating hub territory 

long Priority 

string Storage node; *p* or *t" for persistent or tran- 
sient 

ulong Tiae to live 

Update the mstrhtng RemoteAd with the given values. The system event is forwarded 
to all ooonecssd neighbors except the sendtxandludw that hsve already seen the event 

NXS_SYS_EVEHT_DELI^^ 

long Number of Advertisements A 

Aepeaced A tlses; 
/string/ Advertlseawat, nam 
/string/ Originating hub naaw 
/string/ Originating hub territory 
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Delete the eHociwd RemoeAds «d tditel dam Se»^ ^ onguj^ 



HXS_SYS_EVEMT_REQUEST_ROUTES 



/Mtximj/ S«ndlnq nub 
/acrloq/ Sanding Hub territory 



Ddiver ail muting infonxulioo u> sender widi NXS.SYSJEVENT JtEW_ROUTES. 

NXSjSTSJEVBtT_NEWJK>lJTES 
long Ninbar oC rout«» R 



/string/ AdvsrtLi 

/suing/ Originating hub oim 

/string/ Originating Hub territory 

long Coat 

co«LAdSow*obj» 

local dknta « chocked Cor sobsoxpdai mirhn Tnis may lesoit m a 
NXS.SYSJVEOTJIEW^SUBSaUPTO to *c render rf 

NXS SYS^EVENTJiEW.ROUrES. Each route is considered separately fix 
fcnritttim*Tlie 

that haa already seen the event TT«t^ 
RcaoitAd. or k a cIm 
The cottfleM of ihc fa w ante d 
whkh the cvtiit was received. 



Una system event may mark the end of coonectioQ setup. If the event came from a 
neighbor that is not yet fatty coonecied, 
NXS.SYS JVEOT.OONNBCnON JIEAD Y b sent to the n eighbo r. 

raS^SYS.EVBn-.CHAM^.ROtJTES 

long tttmber of route cnangts R 

/string/ Originating bub nan* 
/string/ Originating bub territory 

Mpeacetf Jt tixamt: 
/string/ adwrtiaeMnt tun* 
long Coat 

QLD^dkecoaof aioufeFU 

cost Yifaft, TV «y**«w U fomttei to all connrc rd neighbors except the tender 
nad neighbar who have already aeeateeveni 

NXSJSYS_EVEMT.OELET5_ROUTES 

long Wsaonr of rout as it 
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/string/ Advertisement rune 
/string/ originating hub 
/string/ otigi nifing hub territory 



DektE tbe tows (AdSource) far the given advertisements (RemoceAd). Any 
subsoiptions which wece fed by (hit torn are failed. This may result an 
NXS SYS JEVBfTJAIL.SUBSaUPnONS aenc to neighbors who hive 
sabecriptions RgisKred far die advertisement Forwanfing cf each deleted tone is 
considered separately and only If the list nuc to tbe advertisement was deleted. Tbe 
system event is not forwarded ao die sender crtb* originating hub. 



NXS^SYS^EVEKT^CHAMCJE^COfWECnON 



/string/ Sending hub 
/string/ Sending hub territory 
long Deita to sanding hub' s connection cost 

Update their cost for die c c coorrin a. 

HXS_SY3_EVENTJC^ 

long Number of subscriptions 5 

Jtepeacetf 5 eiaas: 

/string/ Advertlsaoent naae 

/string/ adtwrtl a ans et hub mm 

/string/ Advertlsoaeat hub territory 

/string/ r liter expression 

along Outer id in sender 

ulong Subscription id in 



Register wb sc t ip dons from the sender sgainst the given edvausexaeas. Create a 
Subscription on te tending neighbor md tail the Bemo^Ad about iL The RemcteAd 
eOs the asxeat AdSoace which oeeies e ^ for the Nd^*oc Of one does not yet 
exist). The Sink s&ls a SobocnprionB^ 



If the advertisement is from another hob, forward a system evens far the new 
subscription to the neighbor ^PPhnm the nmcut tuuts» 



Hie owner and subscription ads aie used to locate the subscription when it is canceled 
and to identify it when it fails. 

K there is a failure during sub s aipti on r eg istr ati o n , an 
NXS.SYS^VENTJAIL.SUBSCPJPTKDNS h seamed to the i 



wcsjSYSjEvanLGAira 

long Muwber of subscriptions S 

ftpeseetf s ex»es: 
ulong Omer id in sender 

ulong Subscription Id in sender 
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Cacel the listed sataaipaoas. This •^cate^^«l£*t««^B«ove 
I^^LsTto *c suhscripticc ban ill canon AdSounxs. Th* sk«ld <We* all 
£SLl>d>e Sufccriptim by Sink oweed Sataaipd«^Ttec^« forced 
to all neighbor* which could poaibly feed tbe subscription. 

KXSJ5YS_EVENT_FA1V_SUBSC«PT10NS 

lon q tfuabar of Xiiiur»» 5 

Pspaatad S eia»s: 

uiono ftau id la raeaivar 

uiong subscription id in raeoivar 
/.trlna/ bum wbar* tailor* occurred 

/string/ Tarritory wt**r« failura ©ecuxxad 

/scring/ Hilur. raaaon 

Senoveiefefencewthesu^^ 

afiected by tbe faBm* If d» subscription was fr»m»Deigi^tl«taautcttfoiwtnlcd 
* back to theorigia*Bftibnb. 

NXSjSYS^EVENTJ ! ORWARO_SUBSC«l ,, nON 

ulong Client id 

uloag Subscription id 



Forward tbe new atacripiiott to negnbon which cm feed it TeU att mas±«* 
the mbamtion. Each toaotcAd fclb io cangat AdSocrcc which 
aesta • Sii± far tbe Oiett Gf aoe does i»t yet exi^ 

far die SafaecnptiaL Seed • NXSJSYS_EVENTJEW_5UBS(»lPn0NS to the 
canon sauce for each noe-local RemoceAd. 



NXS_SY3_EVENT_0ELErE_EVENTTYPE 
string Event typo nam 



Vaavg the evaa type. Tbe system cvcot is forwnded to ail cocnc nnl arigbboci 
except tbe sender and hubs that bare already aeca das cvear. 
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4. Brief Description of Drawings 

Fig. 1 is a block diagram of a networked computer system in 
accordance with a preferred embodiment of the present invention. 

Fig. 2 is a flow chart showing steps performed to install an 
application, such as a publisher, on a hub of Fig. 1. 

Fig. 3 is a flow chart showing steps performed by a publisher of 
Fig. 1 to publish events. 

Fig. 4 is a flow chart showing steps performed by a subscriber of 
Fig. 1 to subscribe to events. 

Fig. 5 is a block diagram showing details of a hub of Fig. 1. 
Fig. 6 is a diagram showing data structures stored in a memory 
of the hub of Fig, 5. 

Fig. 7 is a listing of details of the data structures of Fig. 6 . 

Fig. 8 is a diagram of additional data structures stored in the 
memory of the hub of Fig. 5 for the purpose of storing information about 
clients of the hub. 

Fig. 9 shows a format of an envelope data structure of an event 

Fig.lOshows a format of a routing block of an event 

Fig. 11 is a flow chart showing details of steps performed by the 
hubs of Fig. 1 to populate the data structures of Fig. 6 . 

Fig. L2 is a diagram showing examples of the data structures of 
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Fig. 6 populated with data. 

Fig. 13 is a flow chart showing details of steps performed by the 
hubs of Fig. 1 to send published events to subscribers. 

Fig. 14 is a block diagram of a data base application incorporated 
into the network of Fig. 1. 

Fig. 15 is a flow chart showing steps performed when the data 
base is a subscriber. 

Fig. 16 is a flow chart showing steps performed when the data 
base is a publisher 
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2QQ 



202 



Define one or more 
events (use OMG tOL) 



204 



Compile the iOL to 
structures in the C 
programming language 
(including header file 
and code generation 
file) 



206 



Install advertisements 
for everrt(s) in hub 
connected to the 
application 



Fig. 2 

Installing an Application (Publisher) on a 

Hub 
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300 



\ 

8 -\ 



Register dient tod 
register publications 
•gainst a pre-lnstalled 
advertisement (step 
206) with hub 
connected to the 
publisher 




306 



Create the event (fill In 
structure) 



Publish unpublished 
events 



308 



310 



Destroy the pu Wished 
events 



Publishing Events 
Fig. 3 
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400 



402 



Register client and its 
subscriptions wfth hub 

connected to this 
subscriber (a 

subscription can 
include a content filter) 



404 



Tell the hub to alert 
subscriber wtien an 
event occurs 0.e.. 
register callback 
procedure for each 
subscription) 



N 



410 




Callback function 



Oo something 
with received 
event 



r 



408 



Unreg&er client and 
subscription 



Subscribing to Events 
Fig. 4 



(87) 



#^10-27121 




(88) 



0-27121 




(89) 



1 0-27 121 



The following grvtatta knpo^dittie^ 

Oka id. event quo.. e»«t«ia«c pashoaos^ 

list 

Neighbor turns, id. event qoeae. event qome pi whrnwmn r r , AdSouiceRef list. 
Subscription lilt, my cost, their cow 

AdSouceRet poiner to AdSouxce 

fenuxeAd: nine, eveattype one. p«^.tt^ note. tiiiie«o live, «igfa^ta*. 
^g^triwg territory. AdSouxce list, current AdSoorce 

AdSoarce Sink list, cast 
Safe SBbsenpSca&sf list 
SabacripdooBet pouuer to Subscription 



Subscription: erenttype nsne. filter expression, owner id. Bfaeription id, teforence 
adorignutingfaab) 
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700 



Advert 
Name 


Event 
Description 


Preqof 
Pubfication 


Event 
Type 


Priority 


Time To 
Live 















730 



Registered clients of this hub 
734 



Application 1 liter 
Name | Name 


User 
password 


Hub 
Name 


Territory 
Name 


Flags 


Client 
ID 


i 
1 













760 



Registered publications for this hub 



CJient 
ID 


Advert 
Name 


Publication 
ID 









770 



Registered subscriptions for this hub 



Client 
ID 


Content 
Filter 
Into (if any) 


Event 
Type 


Subscription 
10 











Fig. 3 
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Origin Hub 



Advertisement Name 



Publisher Name 



Territory Name 



initial Time Stamp 



Time To Live 



Priority 



Flags 



List of Subscriber IDs 



Body of Event 



Time Spent 



Fig. 1 

Envelope Format of Event 
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Sequence Number 



Time Stamp 



This Hub's Name 



This Hub's Territory 



Sequence Number 



Time Stamp 



This Hub's Name 



This Hub's Territory 



Fig. ] 0 
Routing Blocks of an 
Event 
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1002 



Distribute Information 
about hub connections 
among hubs 
(Create neighbor 
objects) 



Connect hub 
Connection failed 
Disconnect hub 
Connection ready 
Change connection 



1004^ 



D&ibute event types 
among hubs 



Request event types 
New event types 
Forward event types 
Delete event types 



1006-^ 



Distribute 
advertisements among 
hubs 

(Create RemoteAds) 



Request advertisement 
New advertisements 
Forward advertisement 
Change Advertisement 
Delete Advertisement 



1008^ 



Distribute information 
about routes among 
hubs 

(Create AdSources, 
AdSouce Rerust 

entries) 
(Choose a current 
AdSource for each 
RemoteAd (least cost 
path)) 



Request routes 
New routes 
Change routes 
Delete routes 



101 



Distribute subscriptions 
among hubs 
(Create sinks) 
(Each hub passes 
subscription back 
along least cost path to 
publisher) 



New subscriptions 
Cancel subscriptions 
Fail subscriptions 
Forward subscriptions 



Fig. 1 1 

Populating Data Structures of Hubs 
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1202 



Receive Published 
event from publisher 
attached to this hub 



r 



1203 



Receive published 
event from publisher 
attached to 
neighboring hub 



1204-^ 



Pn processor of hub 
adds envelope to 
event and verifies thai 
this type of event is 
feolsttnid 



Preprocessor of hub 
places event in hub's 
incoming event queue 
flatten throws away 
duplicates) 



120cK^ 



filter gets event from 
incoming evert queue; 
increments time-spent 

field for this event 
(Urne since published) 



Filter adds routing 
block to the event for 
this hub 



Fig. 13 




1212 




Ertract current 
AdSource for this 
publication in this hub 
(via rerooteAd or from 
AdSource) 




1222- 



Throw away event 
(only for his subscriber. 
Check content filters of 
al subscribers) 



Send event to each 

neighboring hub 
connected to a 
subscriber sink object 
(except for the sensing 

hub end hubs that 
have already seen the 
event) 



T 
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Configure data 
base connector as 
a subscriber 



Event arrives 



< 


r 


Data base 
connector stores 
data into data base 
(and commits) 



Fig. 15" 
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1502 



1504-^ 



1506-^ 



1508^ 



Fig. 16 



Inform monitor that DB connector is s nod* 



Configure OB connector as a publisher 



When transaction begins: 
•03 tells tranaction monitor 
-Monger In'owu D5 connector 
•OB connector notes start of transaction 



User makes changes to 03 



1507 



1510^ 




NN. •Oommir? 



•OB tells monitor of commit 
-Monitor informs DB connector 
-08 connector 'pulls* data from DB 



1512 




Monitor informs OB connector to forget about transaction 



1514-^ 
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1. Abstract 

A method and apparatus for publishing and receiving events to a 
network. A plurality of "publisher" entities publish information and a 
plurality of "subscriber" entities request and use the information. 
Publishers and subscribers are connected to each other through a network. 
The network is a "store and forward" network whose routing is "content- 
based." The basic quanta of information is called an "event." Publishers 
publish events and subscribers subscribe to events that match criteria 
defined by the subscriber. Publication and subscription are performed 
asynchronously. Publishers and subscribers do not have direct knowledge 
of each other. The system receives a published event from a publisher 
and routes the event to all appropriate subscribers. Each subscriber is 
guaranteed to receive all events published on the system if, and only if, 
they match the subscription criteria specified by the subscriber. A legacy 
data base can be added to the network by way of a data base connector, 
which can be a publisher, a subscriber, or both. 

2. Representative Drawing 
Fig.l 



